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Foreword 


ISO (the International Organization for Standardization) is a worldwide federation of national standards 
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through 
ISO technical committees. Each member body interested in a subject for which a technical committee has 
been established has the right to be represented on that committee. International organizations, governmental 
and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the 
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. 


The procedures used to develop this document and those intended for its further maintenance are described in 
the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of 
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/ 
IEC Directives, Part 2 (see www.iso.org/directives). 


Attention is drawn to the possibility that some of the elements of this document may be the subject of patent 
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent 
rights identified during the development of the document will be in the Introduction and/or on the ISO list of 
patent declarations received (see www.iso.org/patents). 


Any trade name used in this document is information given for the convenience of users and does not 
constitute an endorsement. 


For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as 
well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical 
Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html. 


The committee responsible for this document is ISO/XXX 


This second/third/... edition cancels and replaces the first/second/... edition (), [clause(s) / subclause(s) / 
table(s) / figure(s) / annex(es)] of which [has / have] been technically revised. 


ISO XXXX consists of the following parts. [Add information as necessary. | 
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Introduction 


It has been expected that blockchain and distributed ledger technologies (hereafter referred to as blockchain/ 
DLT) could be applied to various domains. However, it is uncertain whether there are valuable Use Cases of 
blockchain/DLT and requirements for the technology are not clear. Use Case analysis is helpful to those 
problems as it defines the interactions between an actor and a system enabling to analyse requirements for a 
system. In this document, a wide range of potential Use Cases of blockchain/DLT are described and 
requirements for the technology extracted from Use Cases are analysed in order to help standards 
development. 
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Blockchain and distributed ledger technologies — Use cases 


1. Scope 


This document provides a way to classify Use Cases of blockchain/DLT, potential Use Cases for each 
classified domain and possible requirements for blockchain/DLT extracted from those Use Cases. 


2. Normative references 


ISO/AWI 22739, Blockchain and distributed ledger technologies — Terminology and concepts 


3. Terms and definitions 
For the purpose of this document, the terms and definitions given in ISO/AWI 22739 and the following apply. 


(As ISO/AWI 22739 is currently under construction, terminology and concepts defined in clause 6 of N150 
apply) 

Use case 

Sequence of actions that an actor (usually a person, but perhaps an external entity, such as another system) 
performs within a system to achieve a particular goal. 


NOTE From ISO 17185-1:2014 


4. Acronyms 
DLT Distributed ledger technology 
IoT Internet of Things 


DAPPS Distributed Applications 


S. Characteristics, ecosystem and roles 


Please consult N150 


6. Classification of Use cases 
6.1. General 


Blockchain/DLT could be used for many different applications and purposes. Uses Cases can be categorized 
according to both the domains and types of applications. 


Note this is by no means an exhaustive list of domains of applicability for blockchain/DLT. 
6.2. Domains 

— Agriculture, forestry and fishing 

— Mining and quarrying 
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Electricity, gas, steam and air conditioning supply 

Water supply; sewerage, waste management and remediation activities 
Energy 

Construction 

Wholesale and retail trade; repair of motor vehicles and motorcycles 
Transportation and storage 

Accommodation and food service activities 

Information and communication 

Financial and insurance activities 

Real estate activities 

Professional, scientific and technical activities 

Administrative and support service activities 

Public administration and defence; compulsory social security 
Education 

Human health and social work activities 

Arts, entertainment and recreation 

Other service activities 


Activities of households as employers; undifferentiated goods- and services-producing activities of 


households for own use 


Activities of extraterritorial organizations and bodies 


6.3. Application Types 


Asset management : material, financial and immaterial 
Notarization of transactions proof and timestamping 
Storage of digital proof and tracking 


Smart contract activity 


7. Use case validation 


7.1. Use case validation 


Use cases could be validated through several conditions. The following chart could be a potential validation 


guide.! 
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Is there an issue of trust between 
parties? 


Is there an issue of transparency 
between parties? 


Is there a need for an immutable 
historical record? 


lemmingchain.io 


Invalid use case 





8. Use cases 


8.1. General 
ISO/TC307 Study Group 2 has compiled a list of various potential usage domains and applications for 


blockchain/DLT. It is not an exhaustive list, but it can be used as a starting point for the use cases collection 
process. Collected uses cases are documented in this document. 
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8.2. Submitted Use Cases 
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Use Case ID 


CaseID-001 


CaseID-002 


CaseID-003 


CaseID-004 


CaseID-005 


CaseID-006 


CaseID-007 


CaseID-008 


CaseID-009 


Use Case Name 


Managing lifetime 
healthcare data 


Smart inheritance 
proceeding 


Use of the 
Blockchain for 
securities 


Energy distribution 
with the use of smart 
contracts 


Smart contracts for 
data accountability 
and provenance 
tracking 


Title registry system 
using blockchain 
land ledger 


Reconciliation case 
based on DLT 


Cryptocurrency for 
M2M payments 


Land Development 
Pipeline 
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Use Case Description 


A healthcare use case 
that proposes the use of 
blockchain technology 
and/or distributed 
ledger technologies to 
manage the lifetime 
healthcare data record 
for an individual. 


This use case describes 
a public service 
implementing statutory 
and wilful inheritance 
on blockchain, using 
smart contracts. 


Use of the blockchain 
as a ledger to register 
securities 


A solar energy 
production and 
distribution 
architecture using 
smart contracts, to 
support automatic 
energy exchanges and 
auctions. 


Smart contracts can be 
used to track data 
provenance and encode 
usage control policies 
regulating the access 
and usage (e.g., 
redistribution) of 
subject's data by 
controller and 
processors 


Blockchain real estate 
pilot programs being 
developed for land 
ownership 
administration 


Use of DLT for 
reconciliation to 
streamline and reduce 
the settlement period 


Using cryptocurrency 
for Machine to 
Machine (M2M) 
payments 


Recoding land title 
ownership using 
blockchain 


Domain or 
Industry 


Type of 
application 


Human health 
and social work 
activities 


Public 
administration 
and defence; 
compulsory 
social security 


Financial and 
insurance 
activities 


Other service 
activities 


Real estate 
activities 


Financial and 
insurance 
activities 


Financial and 
insurance 
activities 


Real estate 
activities 
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CaseID-010 Commercial fish A blockchain solution Agriculture, 
stock management for the effective forestry and 
management of fishing 
commercial fish stocks 
in wild fisheries 


CaseID-011 Identity management Blockchain and DLT Public 
with the use of systems that providea administration 
Blockchain for “Trust Framework” to and defence; 
Border control enable seamless travel compulsory 
and enables privacy, social security 
security and identity 


CaseID-012 Supply chain Using blockchain to Supply chain 
management and the record provenance management 
use of blockchain across complex supply 

chains to enable 
efficient trade, reduce 
fraud and access to 
trade finance. 


CaseID-013 Energy certificates of Decentralized 
origin application which 
enables any trusted 
renewable generator to 
sell green attributes 
peer to peer. 


CaseID-014 Sharing economy Using blockchain and Other service 
DLT to operate a activities 
sharing economy 
without a centralized 
platform. 





Table 1 — Submitted use cases 


9. Use cases (subject to change depending on collected use cases) 
9.1. General 


9.2. Identity Management 


9.2.1.General 


Identity is a daily fact of life for people. People are asked for identification for various activities and 
transactions (e.g. checking in at the airport, performing a financial transaction at the bank, visiting the doctor). 
Identity documents such as of birth certificates, passports, and other government issued IDs are usually 
presented as proof of an individual's identity. They usually contain some personal information and a picture 
for easy identification. In the online world, identity is also critical for many applications and transactions. 


Identity as defined by ISO ISO/IEC 24760-1:2011 is a set of attributes related to an entity. Authentication is 
the formalized process of verifying identity information associated with a particular entity. Online applications 
usually perform an authentication process to obtain the current user's identity. 


Blockchain/DLT can be used to store digital identities that are certified by an identity authority (e.g. 
government) and other relevant personal information. This provides assurances to recipients of such identity 
information that the identity is genuine. Since other relevant personal information may be stored with the 
identity, the blockchain/DLT ledger may also be used as a personal information store or as an attribute verifier 
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that verifies certain characteristics without giving out personal information (e.g. lives in a certain region, of a 
certain age group). Privacy, security, and access control are top concerns for such applications. 


Identification does not only apply to people. It can also apply to corporations, assets in the real world, 
products, and parts, etc..... Since identity is of such high importance, questions on how to accurately store and 
identify various entities or objects on the blockchain/DLT need to be addressed. 


9.2.2. Identity management with the use of blockchain for border control 
9.2.2.1.Brief description 


The effective management of identity at border controls is a process that brings together international 
governments, world trade businesses, travel services and billions of people. The opportunities for Blockchain 
technologies in Border Control includes a wide range of infrastructure applications from transport hubs to 
political borders and site access. 


In this use case, we consider the specific application of Identity at Airports, and how they are taking advantage 
of the potential of blockchain technologies. With the number of global air travel passengers forecast to nearly 
double to 7 billion people by 2030, and Airlines and airports to invest $33bn in IT in 2017, new approaches 
are needed to address the challenges and opportunities for security, logistics and personal identity across 
global hubs and interconnected infrastructure platforms. 


A number of initiatives are planned and being developed with blockchain solutions to offer a new, seamless 
and more secure travel experience fit for the 21st Century. The application of this business opportunity was 
announced by the Dubai Government in April 2017 and this use-case has extended with WEF announcements 
at Davos in January 2018. 


This use cases presents a fundamental rethink in how government and private companies can improve the way 
they connect and interact by releasing the value of blockchain and related new technologies, based on a 
permissioned based Identity trust framework. This trust framework concept, known as ‘Self-Sovereign 
Identity’ (SSID) assumes an Individual has control over their identity, where the data is decentralized, and 
where an individual exerts that control by providing consent to share their data in order to access services. 


This process is illustrated through a use-case of an individual passenger taking an international flight through 
global airport hubs. 


The potential for this model includes: 
e global reach, e.g.: the fastest Air travel growth forecast for Chinese and India passengers 
* multiple vertical implications as the Identity Asset can be shared with all of government services (e.g.: 


banking, health, education), international travel services (e.g.: hotels, transport, insurance) access 
(e.g.: security, offices, hazardous sites) and applications for inclusion (e.g.: refugees and unbanked). 


9.2.2.2.Detailed description 


In this model, we address the Identity problem of multiple points of friction across at airports or border 
crossing. These include: 
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* Logistics: as air travel is forecast to double over the next 20 
years to 7.8bn passenger journeys (IATA), airports and the 
related government and travel services are challenged to 


manage this capacity and handle the efficient processing of 2017 Air passenger 
passengers. economics and demand 
volume 


* Customer expectations: customers have increased expectations 
in terms of privacy, personalised services, safety and 
convenience 2017 in review - air passenger volumes 


* Airport commercial model: Airports seek to raise revenues 
from shopping and other services, where the global duty-free 
industry is expected to grow to $67bn by 2020 


* Security: the increasing cyber and physical risks in areas of 
travel, queues at barriers and gatherings of people in large 
queues 


The model is divided in four layers: 
a) the identity of a person (e.g.: air passenger) 


b) the identity of authorised entities (e.g.: government, travel 





and security agencies) 


Reference: IATA 2017 in Review - air passenger 


c) the identity of things (e.g.: luggage) 
d 


economics and demand volumes 


the identity of processes (e.g. logistics of borders, 


— 


bookings or flight plans) 


9.2.2.3.Scope and objectives 
The main aim of the Use Case is to enable seamless travel with the uses blockchain and DLT systems that 
provide a "Trust Framework", and enable solutions to privacy, security and identity. Key principles of the 
scope and objectives include: 


— the use of Self Sovereign Identity (SSID) as a model for permissioned data sharing between multiple 
stakeholders 


— the principle of Inclusiveness for a global world 

— the Identity system is agnostic to any particular blockchain and/or is inter-operational 

— the model has flexibility to accommodate and respect local and national laws and regulations 
9.2.2.4.Additional information 
9.2.2.5.Context/Setting 
In this use case, we see the journey of an individual traveller as they go through an international border. 


Traditionally, the travel process has used paper-based tickets, boarding passes and passport books. Users are 
increasingly going digital, and airports are automating the process using e-gates, scanning devices and kiosks. 


Blockchain and other technologies such as improved Biometrics, bring the opportunity to make a significant 
shift to seamless travel. This journey sees: 
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— Asset creation: An individual creates a SSID to create a rich data profile for passports and ticketing. 
Blockchain provides a platform to encrypt data, provide permissioned sharing and attestation by 
various bodies. 


— Asset tracking: The ability for a Passenger’s SSID to provide permissioned tracking at appropriate 
levels through the Border journey (e.g.: passport and visa control) and permission access to 
additional data from a more robust profile of historical or real-time factors (e.g.: recent travel history) 


— Cryptography: ongoing development and future-proofing of cryptography capabilities 


— Smart Contracts; Smart Contracts enable to provision of Consent, with the ability of time-stamping, 
conditional agreements, and expiry process to manage privacy and risk for all stakeholders. 


— The diagram below illustrates the context of the new Blockchain enhanced Journey, with a customer- 


centric approach with multiple User interactions of different actors and the potential for process 
efficiencies 


Identity in the Airport Borders Journey 





The Travel Journey has multiple Painpoints that can be 
impacted and improved by and effective SSID System 


. Efficient pre-travel booking to upload an Individual’s 


Wallet of Travel Data & Passport details se 
"n = 
. Faster Airport Departure checks and processing, more fiii tb. & 





time for shopping. Personalised Inflight experiences 
. Faster Airport Arrival checks and processing, more time 


for shopping and meals 





T" : a : Holiday/Business 
. Efficient arrival to destination services (Transport, Hotel, 


à wu mA aaa os 
Business, Entertainment) N S iii wii ia 
~ — B 4ta TY 
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9,2.2.6.Actors 


This is a list of actors in the use case. 


Actors 


Actor name Actor type Actor Description Additional Information/ I d e n t i t y 
technology types(Natural 


persons/Legal 
entities/Things/ 
Process) 
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Passport Government 
Office 


Travel User 
company 


Passenger User 


Security System 


services 


Airport/ System 
Airline staff 
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The entity Legal entity 
responsible for 
checking 
immigration 
processes. This 
includes the 
identity and validity 
of passengers (e.g.: 
passport and visas) 
and ability to 
address un- 
identifiable people. 


The entity The Travel company is Legal entity 
responsible for the first channel of 
KYC processes to identity processing. The 
ensure correct other stakeholders 
passport and visa provide further identity 
information is processes. 

collected for 

airlines, 

immigration and 

security 

stakeholders 


The Individual Natural person 
responsible for 

managing the 

validity of their 

passport, visa and 

legal identity 

attributes, and 

meeting travel 

logistics. 


The entities Legal entity 
responsible for 
International and 
local management 
of security 
processes e.g.: 
security and safety, 
customs, 
regulations, 
trafficking, terrorist 
monitoring etc. 


The individuals and These actors may be Legal entity 
entities responsible separated into air-side and 

for check-in, land-side responsibilities. 

services, departure 

and arrival 

processes in 

airports, airlines 

etc. including 

identity of People 
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9.2.2.7.Interaction between Actors and User Requirements 
9.2.2.8.Use case diagrams / tables 


The diagram below illustrates the interaction of Blockchain and off-chain processes. It includes the features of 
SSID, Public or Private Keys, Attestations, and Blockchain nodes. 


Outline Architecture 
INDIVIDUAL IDENTITY (PRIVATE KEY) 
USER INTERFACE 
MULTIPLE DEVICE ASSETS H U 
EG: PRIVATE KEY & ATTESTATIONS 


LEAN SERVICES COMMS STANDARD 


CLOUD BASED DISTRIBUTED SECURITY LOCKERS 3 


IDENTITY VERIFIERS SERVICE PROVIDERS 


MULTIPLE ASSETS (OFF CHAIN) DECISION BASE FOR REGULATORY COMPLIANCE 
EG: BIOMETRICS, BEHAVIOURAL ETC 


ACTIVITY: ATTESTATION PROCESSING ACTIVITY: Request & EVALUATE ATTESTATIONS 


DLT/ BLOCKCHAINS 
AGNOSTIC & INTEROPERABLE (EG: IBM HyPERLEDGER/ ETHEREUM ETC) Vn 
ACTIVITY: SMART CONTRACTS, PERMISSION BASED, CRYPTO 
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9.2.2.9.Data Flow Diagram of Use Case 
9.2.2.10.Pre-conditions or requirements or assumptions 
Assumptions include: 


* Adoption models such as government led initiatives for trusted travel applications e.g.: e-visas and 
digital passports 


e  Off-chain storage: All use cases assume integration with off-chain systems, from front-end devices 
through to off-chain storage. 


e IoT integration: Blockchain will be able to interact and be future proof for multiple IoT assets, from 
biometrics to suitcases. 


* Device agnostic: The ability for users to move beyond the mobile app, to multiple devices 

* Access: The existence of suitable open network access (internet via Wi-Fi, for instance) at airport 
locations, but the system will employ communications “LEAN standards" to enable operations in 
areas with low or intermittent network connections. 


9.2.2.11.Post-conditions 


With the use of the proposed system, the seamless travel processes will offer efficiencies to process the rapid 
growth in air travel passengers in airports, where capacity constraints exit. 
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9.2.2.12. Technical architecture of the use case (optional) 


9.2.2.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.2.2.14.Security and privacy 
There are fundamental User principles and attributes required of the system: 
e I want to feel safe and secure 


e I want my data to be private, and only share what is strictly necessary, and only with the authorised 
agencies (e.g.: strengthened by GDPR regulations in 2018) 


e I want convenience in travel and will consent to sharing relevant information to gain greater 
convenience or service 


e I will conform to reasonable requests for my personal information by authorised agencies (e.g.: such 
as a security alert) 


9.2.2.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 

9.2.2.16.Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.2.2.17.Relations with other known use cases (optional) 

9.2.2.18.Smart contracts used (optional) 

9.2.2.19.Merit over traditional ledger 


Blockchain offers specific attributes over a traditional ledger, that reflects the shift from centralized to 
decentralized systems: 


e  Reiterating, authorization and sharing an individual's details 
* Zero Knowledge proof, for the attestation of data among multiple authorised stakeholders 
e Data is immutable which minimizes fraud 
e Blockchain ensures the details have been shared, is timestamped and becomes a digital record 
e . My details are used once; it’s not up to the borders to share. 
9.2.2.20.Use case concerns, issues 


A User always has the option and control to permission and shares the data, subject to local laws or 
regulations. 
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9.3. Finance 
9.3.1.General 


Finance in blockchain/DLT relates to the transfer of assets between participants in the ledger network. It is the 
settlement processes of a traditional financial transaction. Assets can be currency, securities, commodities, 
derivatives, or any "digitized assets" that represent assets. Transactions can be as simple as transferring some 
unit of currency from one participant to another or as complex as the entire process of settlement of 
commodities across multinational borders. Traditional settlement processes involve multiple financial 
intermediaries and may require manual processes. Smart contracts used in the blockchain/DLT may automate 
some processes when certain criteria are met, removing some intermediaries, thereby increasing efficiency, 
speed, and reliability. 


9.3.2. Reconciliation use case bbased on DLT 
9.3.2.1.Brief description 


Today, the traditional reconciliation process between different banks often takes as long as T+1 or T+2 days. 
This long reconciliation time both creates inefficiencies and can lead to information asymmetry. 


By enabling reconciliation with a distributed ledger, blockchain technology can streamline and reduce the 
settlement period to T+0 days from the industry average of T+1 to T+2 days today. 


The platform is a pioneering blockchain application for a “distributed business scenario", wherein a high level 
of interbank operational efficiency, process automation and system reliability are required to ensure cost 
efficiency and business continuity. 
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9.3.2.2.Detailed description 


This platform was to facilitate the clearing and reconciliation process for online, unsecured consumer loans 
via mobile devices. The loan is underwritten under a syndication model, wherein funding is jointly raised by 
the lead bank and other participant banks. To ensure a smooth customer experience during the drawdown 
process, participant banks are required to make advanced deposits of provisional funds in the VOSTRO 
accounts opened at the lead bank. However, the process involving interbank clearing and settlement, as well 
as account reconciliation, grows increasingly complex as the number of participants increase. 


In the traditional syndication model, banking systems only allow participant banks to view transaction 
journals and make reconciliations on a T+1 basis. The account information asymmetry in this process may 
increase participants’ cost of capital, but the development of a real-time reconciliation system by independent 
participant banks is also not financially plausible. Nevertheless, a demand for visualized tools to monitor 
clearing and settlement and timely reconciliation remain in demand. 


This platform is an ideal solution to the aforementioned issues. System statistics also support this business 
case as well. The platform is used by three participant banks. 


9.3.2.3.Scope and objectives 


The objectives of the platform include simplifying the interbank reconciliation process, improving operational 
efficiency, and reducing operation costs. 


9.3.2.4.Additional information 

Through this platform, transaction journals of loans and provisional funds can be posted on the blockchain 
network, allowing participant banks to view VOSTRA account balances and loan transaction journals almost 
in real-time time. In addition, the platform generates a daily summary of reconciliation results. 

The future technological development of this use case for commercial use is faced with several challenges. To 
address these, the solution strives to be extremely safe and robust, be both approachable and widely adopted, 
and be compliant to related laws and regulations. 

The practical development of this use case lies in how it optimizes DLT to satisfy myriad high-frequency 
transaction scenarios. To this end, DLT should be designed to operate 24/7and only allow for extremely short 
downtime even in extreme cases. To really put the business model into practice, the platform should provide 
various service ports, making it convenient for programmers to configure and call up smart contracts. 

In relation to regulation, since there will be digital signatures in all transactions on the Blockchain and the 


transactions cannot be tampered, regulators are able to join to sync all transaction data on the chain, which 
avoids incompleteness and inconsistencies of reporting data from different institutions. 


9.3.2.5.Context/Setting 

This is a brief description of the context/setting/industry surrounding the use case. 

Use case vertical application field/domain: e.g. financial services, manufucturing... 

Use case vertical subdomains: e.g. cryptocurrency, mutual funds... 

Use case horizontal activity: e.g. asset management, notarization... 

The vertical application field of this use case is the financial services. The vertical subdomain is 


reconciliation, clearing, and settlement of financial transactions. The horizontal activity of this use case 
belongs to the domain of notarization of transactions proof and timestamping. 
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9,3.2.6.Actors 


Actors 


Actor name Actor type Actor Description Additional Information/ I d e n t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Technology and Provide all data Legal entity 


platform provider; records; 
Lead Bank Master Node 
Platform operation 
and maintenance 


Loan co-issuer; Only responsible Legal entity 
Light nodes for 
reconciliationion 


Participant 
Banks 





9.3.2.7. Interaction between Actors and User Requirements 


This use case is designed for inter-bank application. Firstly, the clearing and reconciliation process involves 
the high-frequency, high-volume information and fund flows. At the same time, the operational management 
must meet strict access and security requirements. As a result, a Consortium Blockchain arrangement is an 
ideal choice for this platform. 


In this use case, credit initiation, loan drawdown and repayment, and transaction posting are processed in the 
lead bank's IT system. The platform has made some improvements based on the RAFT algorithm and 
developed a single-node based consensus algorithm (Master-Node-Based Consensus Algorithm). At the same 
time, this blockchain network also applies a plug-and-play design to be more flexible, allowing for the 
swapping in or out of other consensus mechanisms, such as PBFT, in future business scenarios according to 
the situational need. On the other hand, the participant banks only need to query information for position 
monitoring and risk control. 


9.3.2.8.Use case diagrams / tables 


Partener Bank ( Blockchains ( Tencent Lead Bank 
Production Cloud ) 
Environment ) 


Reserve Fund Query 
4 Intranet E System 


Acess 


I 

Participant Bank l 
Administrater l 
I 
[ 
I 


Pre-set Blockchain 


Lead Bank 
Node J 
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9.3.2.9.Data Flow Diagram of Use Case 
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9.3.2.10.Pre-conditions or requirements or assumptions 
The application of this use case is based on two pre-conditions: 
* Operations involve multiple banks. 
* Fund flow and information flow are separated. 
* One lead bank provides the core technology. 
9.3.2.11.Post-conditions 
9.3.2.12. Technical architecture of the use case (optional) 


9.3.2.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.3.2.14.Security and privacy 
* This platform applies the asymmetric encryption algorithms RSA and ECC. 
* During the process of data transferring and recording, all the information is encrypted. 


* All the information on the chain has been through desensitizing process to get rid of the private 
information about users and the participant banks. 


* At the same time, the blockchain network and the original bank core system are completely 
independent at the logical and physical layers and do not affect each other. The data in both 


transmission and storage is encrypted to ensure safety and security. This design follows the guidance 
and strict supervising requirements of certain regulations. 


9.3.2.15.Legal considerations (optional) 


Legal Contracts, Legal Regulations, and Constraints 
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9.3.2.16.Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.3.2.17.Relations with other known use cases (optional) 

9.3.2.18.Smart contracts used (optional) 


Every time a new transaction happens, the transaction and fund movements will trigger one smart contract to 
initiate the reconciliation process automatically. The fund movements then trigger another smart contract to 
calculate the end balance of the fund account from the transaction movements. 


9.3.2.19.Merit over traditional ledger 


Through this program, participant banks can obtain near real-time information of from the transaction journal 
and reserve fund balance movements to improve operational efficiency — all without the need for developing 
additional systems by themselves, shortening the reconciliation cycle from T + | to real-time (T+0). 


9.3.2.20.Use case concerns, issues 


9.3.3.Cryptocurrency for M2M payments 


9.3.3.1.Brief description 


IoT devices are becoming more and more mainstream as more people consider them as indispensable tools for 
everyday usage. The increasing capabilities of IoT devices allow them automate many tasks. This use case 
explores the use of cryptocurrency as an alternative method for Machine-to-Machine (M2M) payments. 


9.3.3.2.Detailed description 


The Internet of Things (IoT) commonly refers to the wide range disparate devices such smart devices, objects, 
wearables, vehicles, buildings, machines, and electronics embedded with hardware and software, that connects 
to and communicates via the Internet. The adoption of various new concepts and technologies (e.g. security, 
big data and analytics, cloud computing, artificial intelligence and machine learning, etc....) and increasing 
capabilities of devices paves the way for a new applications, services, products, and business models. 


Machine-to-Machine (M2M) payments refer to the application of financial transactions between IoT devices. 
This functionality facilitates the ease and speed of consumer purchasing via IoT devices, thereby making them 
potential important points for commerce and usage based services. 


Payment models already exist for M2M payment transactions. Typically, these models involve saving personal 
and financial information locally on the device, remotely in a cloud service, or sending the payment 
information to third-party payments providers. This exposes the consumers' information to risks of being 
stolen or used without authorization. 


Cryptocurrency can be an alternative to traditional payment methods. Centralized IoT architectures may have 
difficulty keeping up with resource demands of ever increasing IoT devices. The decentralized, peer-to-peer 
nature of blockchains and distributed ledger technology makes cryptocurrency suitable for M2M payments 
between devices. Cryptocurrency provides a reliable way to make M2M payments in a decentralized manner 
thereby relieving strain on centralized systems resources. 
Cryptocurrency provides the following advantages: 

* Security 

* Transaction control 


* Privacy 
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* Ease and speed of payments 
* Low fees 
* Transaction transparency 


The cryptography used in crytocurrency ensures that transactions are secure. Only the owner of the digital 
wallet can make payments from the wallet. 


Crytocurrency offers control over transactions. The owner of the digital wallet initiates all transactions. The 
owner explicitly sends a payment directly to a receiver. There are no other intermediaries involved compared 
to payment systems such as credit cards where transactions may pass through multiple intermediaries and may 
be declined in the process. 


Personal information is not sent with cryptocurrency transactions thereby protecting the privacy of the sender 
and reducing the risk for identity theft. 


Cryptocurrency makes sending payments fast and easy. It only requires the wallet address of the receiver to 
send payments. This makes it very suitable for M2M payments where ease of use can drive adoption quickly. 
Cryptocurrency can be sent to anyone, anywhere, at any time. It is not subject to national borders or third 
party operational hours. Settlement time may depend on the cryptocurrency. 

Transaction fees may be lower compared to other monetary transactions since there are no other 
intermediaries involved. Lower fees make using cryptocurrency a feasible option for M2M payments 
especially micro or nano payments. 


Cryptocurrency transactions are transparent. All transactions are verifiable by a third party. Fraudulent 
transactions are discovered and eliminated. 


9.3.3.3.Scope and objectives 

With increasing IoT device usage, M2M payments can simplify the payment process for services and goods. 
The scope is to explore the advantages and disadvantages of cryptocurrency as a payment method that is safe, 
secure, and private for use in IoT devices. 


9.3.3.4.Additional information 


This is additional information related to the use case, including a listing of potential economic and non- 
economic benefits. 


9.3.3.5.Context/Setting 

This is a brief description of the context/setting/industry surrounding the use case. 
Use case vertical application field/domain: financial services 

Use case vertical subdomains: cryptocurrency 


Use case horizontal activity: 
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9.3.3.6.Actors 


Actors 


Actor name Actor type Actor Description Additional Information/ I d e n t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Alice Person Consumer Natural person 


CarA Device IoT device Thing 
belonging to Alice 


BigOil Corporation Merchant Legal entity 


PumpB Device IoT device Thing 
belonging to BigOil 


BigCity Government City Government Legal entity 
Entity 


BoothC Device IoT device 
belonging to 
BigCity 

ParkingOp Corporation Parking lot operator Legal entity 
IoT device 


belonging to 
ParkingOp 





9.3.3.7.Interaction between actors and user requirements 


In this use case, Alice as the consumer owns a vehicle CarA that is embedded sensors, electronics, and 
software that can perform various automated tasks, including payment services on behalf of the owner. 


Alice needs to get from point A to point B and gets into her vehicle and starts it. 


1. Upon start-up, CarA’s sensors detects that the fuel is low and directs Alice to proceed to the nearest/ 
cheapest fuel station, BigOil. 


2. Alice arrives at BigOil and parks the vehicle next to a fuel pump. 


3. CarA's sensors detect how much fuel is required and communicates with PumpB regarding how much 
fuel 1s needed and pricing information. 


4. CarA prompts Alice to authorize the transmission of funds from its digital wallet containing the 
cryptocurrency. 


CarA could be configured to use Alice's digital wallet or it can have its own digital wallet. In the case 
that it's has its own digital wallet, it may have a smart contract with Alice's digital wallet to transfer 
funds when it's account balance falls below a pre-set level. 


5. PumpB confirms receipt of the funds and the fuel is dispensed, either manually or some through 
some form of automation. 


6. Alice proceeds onto destination B. 
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7. On the way, Alice passes through a toll bridge, which requires payment of a toll to BigCity, the 
operator of the bridge. 


8. CarA’s sensors detect BoothC and communicate with it to get current pricing. 

9. CarA automatically sends the funds to BoothC and notifies Alice of the transaction. 
10. BoothC verifies receipt of bridge toll and allows CarA to cross. 

11. Alice arrives at point B. 

12. At point B, Alice needs to park the vehicle. 

13. CarA directs Alice to ParkingOp’s lot. 


14. CarA detects LotD and gets pricing information and prompts Alice for authorization to send the 
parking fee. 


15. LotD verifies the receipt of parking fee and the CarA is allowed to park. 


This use case scenario is very common and each part is already achieved with present day technology without 
the use IoT devices. For purchasing fuel, Alice can use digital wallet her mobile device, which is set with her 
credit card or other financial information. When crossing the bridge, sensors on the bridge detects the 
transponder tag on CarA that is registered to Alice. For parking the car, Alice may use her mobile device to 
pay or her credit card. In each of the payment scenarios, payment was sent except it was done non-uniformly 
and manually. Alice needs multiple devices and needs to configure or register each one separately. In any case, 
personal and financial information is sent to the services and goods providers. M2M payments streamline the 
payment process to give consumers a more seamless and pleasant user experience, provided that the hardware 
and software is available to perform such actions. Cryptocurrency adds a layer of control and security to the 
payments process. 


In a more futuristic and autonomous scenario, the vehicle will be capable of driving itself. Alice contacts her 
vehicle via a mobile device or an implanted device within her body. The vehicle picks her up and Alice 
informs the vehicle of the destination. The vehicle automatically navigates to the destination, drops Alice off, 
and then parks itself, paying all required tolls and fees along the way. 


As another alternative, Alice might not even own the vehicle. She could just contact a taxi service for 
transportation. Her personal IoT device will communicate with the taxi service and vehicle and handle all 
payment transactions. Cryptocurrency used in the process acts as real money. No personal or financial 
information is exchanged, thereby keeping her information safe and secured. To keep her privacy more 
secured and to prevent tracking, her IoT device might even create one-time use or discardable cryptocurrency 
accounts to send payments. 


9.3.3.8.Use case diagrams / tables 
9.3.3.9.Data Flow Diagram of Use Case 
9.3.3.10.Pre-conditions or requirements or assumptions 


There are various cryptocurrencies in use, but M2M payments may involve miniscule transaction amounts so 
a cryptocurrency that has little or no transaction fees need to be considered. 


Also settlement times need to be short or at least acceptable within the context of the transaction. Transactions 
that involve a live person may require near real-time settlement times whereas a vending machine ordering 
new inventory may not require such. 


M2M payments can be highly automated so it is assumed the IoT devices have enough hardware, sensors, and 
software that allow them to detect that they are in the vicinity of each other and there is a common 
communications protocol that allows them to perform discovery and negotiate services or goods. 
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9.3.3.11.Post-conditions 


In this payment scenario, the end result is that the consumer's IoT sent payment to the recipients. The 
transaction amounts are deducted from the consumer's cryptocurrency account and added to the recipient's 
cryptocurrency account. The transactions can be verified in the cryptocurrency ledger. 


9.3.3.12. Technical architecture of the use case (optional) 


9.3.3.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.3.3.14.Security and privacy 


There are security and privacy concerns regarding the usage of cryptocurrency. Since one of the main features 
of cryptocurrency is transparency, it is possible to track and analyse all past and possibly future transactions of 
a particular account. Even though, the account owner information is private, the fact remains that the account 
(number) itself is permanent. Therefore, it is possible to track and gather information for any account. The 
gathered data can be analysed to form transaction patterns such as to transaction participants, time and 
frequency, transaction volume and amounts, and account value. If the real identity of an account is known 
(e.g. the account is used by a particular vending machine at a certain location), then it is also possible to track 
information such as geo-location data and possibly infer what services or goods were involved in the 
transaction. If the account holder is a corporation, then it may be possible to gather confidential information 
such as business partners and contractors, customers, account value. Transparency is an advantage or 
disadvantage depending of the point of view of the participant, so consideration must be made carefully. 


Cryptocurrency transactions are secure but depending on the cryptocurrency and the model used to validate 
and write transactions to the blockchain, transactions can possibly be manipulated. For models that depend on 
consensus, which is determined by the computing power of the cryptocurrency network, it is possible but 
highly unlikely that transactions can be manipulated by controlling just over 5096 of the computing power. 


9.3.3.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 

The legality of cryptocurrency differs from region to region. Depending on the region it is used, 
cryptocurrency could be legal, illegal, unspecified (not explicitly legal, yet not illegal), or may be heavily 
regulated. 

In cases where the cryptocurrency is accepted but is not issued by a monetary authority, it may not be 
considered legal tender and may not have legal protections. Also, there may not be guarantees to convert the 


cryptocurrency to local currency. These conditions may lead to situations where the cryptocurrency cannot be 
used without additional actions or conversions to/from other currencies. 


9.3.3.16.Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.3.3.17.Relations with other known use cases (optional) 

9.3.3.18.Smart contracts used (optional) 


There may be a smart contract in place, which allows the IoT device to replenish funds from its owner's 
cryptocurrency account when its own account balance falls below a pre-set level. 


There may be smart contracts between Alice's IoT devices and various goods or services providers to send 
payments for services or goods. 
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9.3.3.19.Merit over traditional ledger 
9,3.3.20.Use case concerns, issues 


The following are some issues that need to be taken into consideration before adopting crytocurrency for 
M2M payments: 


* Unfamilianity and limited adoption 
* Price volatility 
* Losing access to cryptocurrency 


Cryptocurrency is not yet widely adopted. It could be due to the reason that people are still not familiar with 
the currency. People do not understand how the currency works and thus will not choose to use it. The lack of 
popularity will not increase mainstream awareness of the currency. This creates a vicious cycle where one 
cannot progress without the other. Educational efforts are needed to teach people about cryptocurrency and the 
proper ways to use it to protect users from exploitation. 


Cryptocurrency is subject to price volatility. Depending on the value of the cryptocurrency, consumers may 
overpay or underpay for a transaction and likewise, recipients may receive more or less than the transaction 
value. Speculation in the cryptocurrency market causes wide swings in value. This results in less people 
adopting cryptocurrency. It is expected that cryptocurrency value will stabilize with increasing usage but it is 
another chicken or the egg problem. 


Cryptocurrency is equivalent to digital money. Unlike real money, cryptocurrency is immaterial and is only 
digital information stored somewhere. Once, the information for the private keys related to the account is lost 
(e.g. storage medium failed, information is corrupted or deleted, or access to information store is lost or 
revoked), the cryptocurrency is lost forever. It is virtually impossible to reconstruct the private keys unless a 
backup copy exists. Multiple backups and appropriate safeguards for the keys are needed in order to prevent 
loss. 


9.4. Healthcare 
9.4.1.General 


Healthcare involves products and services related to the health of people. It can be something as simple as a 
medical check-up, the entire process to research, develop, test, approve, and produce a new drug, or even the 
billing for the medical services. The transparency, immutability, and traceability characteristics of blockchain/ 
DLT can be used to address many issues in the healthcare industry. 


The existence of multiple healthcare providers creates an identification problem. Different healthcare 
providers may have different identifiers for the same patient, causing problems in patient identification and 
exchange of healthcare records. Registration of patients and providers in a national or multi-national ledger 
helps alleviate patient and provider identification problems. 


Blockchain/DLT can be used as a foundation for a platform to store and share medical history of patients. 
Keeping the complete medical history in one place facilitates diagnosis and treatment of patients by giving 
providers easy access to patient information with full confidence that the information haven't been tampered 
with. Anonymized data can be mined and analysed with patient approval. Immutability, traceability, 
transparency, and security of records also enable blockchain/DLT to be used for storing, sharing, and auditing 
of clinical and research data. These same properties also lend itself for the production chain of medical drugs 
to combat counterfeit drugs by monitoring each phase of production. It can also be used to keep track of drugs 
post-production in case of problems. 
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9.4.2.Managing lifetime healthcare data 
9.4.2.1.Brief description 


A healthcare use case that proposes the use of blockchain technology and/or distributed ledger technologies to 
manage the lifetime healthcare data record for an individual. 


9.4.2.2.Detailed description 


An individual’s lifetime healthcare data record may currently consist of multiple datasets stored in various 
databases or storage units, across multiple healthcare providers. These datasets may be stored using different 
data formats across various storage mediums (i.e. digital, hardcopy). 


The disjointed nature in which an individual’s lifetime healthcare data record can be stored makes it extremely 
difficult for an up-to-date and accurate lifetime healthcare data record to be kept. 


In instances where an individual’s complete healthcare data record is accurately managed by a healthcare 
provider, the sensitive nature of said healthcare data makes the timely sharing of such information between 
healthcare providers extremely difficult [1]. 


Therefore this use case proposes the use of blockchain technology and/or distributed ledger technologies to 
manage the healthcare data record for an individual over their lifespan. A shift towards a new technological 
paradigm, in particular blockchain technology, would offer a range of benefits for the management of such 
healthcare data records. Two sample benefits are outlined in subsequent sections 2.1, 2.2. 


9.4.2.2.1. Harmonisation of Healthcare Data Regulations 


At present the regulatory requirements placed on healthcare data are jurisdictionally dependent. Certain 
jurisdictions place extensive regulatory requirements on the collection and storage of healthcare data, whereas 
other jurisdictions do not. Even in jurisdictions that have extensive regulatory requirements, the specifics of 
said requirements can differ greatly between zones of jurisdiction. 


For example data protection laws governing the collection and storage of healthcare data in countries within 
the European Union differ from data protection laws governing the collection and storage of healthcare data in 
the United States of America [2]. 


In such a multifarious domain, the introduction of blockchain technology has the potential to harmonise 
healthcare data regulation across participating jurisdictions. 


9.4.2.2.2.Ownership/Access of Healthcare Data 


Moving the management of an individual's lifetime healthcare data record to a blockchain enabled solution 
would allow an individual to retain complete ownership of all of his/her healthcare data throughout their 
lifespan. 


As an individual's lifetime healthcare data record can be considered to be a highly sensitive dataset. Therefore 
access to said dataset should be subject to the strictest of access control protocols. The cryptographic 
techniques blockchain technology leverages for its successful operation; specifically public-key cryptography; 
offer a succinct and elegant solution to the problem of access control in relation to an individual's healthcare 
data record. 


Through the use of public-key cryptography a healthcare provider would only be permitted to access an 
individual's healthcare data record if specifically authorized by the individual in question. This access could 
be limited in scope (e.g. read-only, write-write) and time dependent. Furthermore, smart contracts could be 
utilised to ensure an individual's healthcare data record 1s kept accurate and continually update to date. 


9.4.2.3.Scope and objectives 


The scope of this use case is to provide a potential use case for blockchain technology and/or distributed 
ledger technologies in healthcare. 
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Additional information 


Practical implementations of this use case might employ the usage of one or more blockchains operating on a 
distributed network. This would be dependent on conditions such as the size, structure and potential usage of 
healthcare data in question. 


This use case may be viewed as a progressive and somewhat unconventional approach to the management of 
an individual’s lifetime healthcare data record. However, it should be noted that it is the author’s opinion that 
the implementation of such a use case could be considered to equate to the effective end goal of many existing 
organizations such as The European Institute for Health Records (EuroRec) [3]. 


9.4.2.4.Additional information 


9.4.2.5.Context/Setting 


This use case relates to healthcare the industry and those who operate within it. In particular, it focuses on 
healthcare providers; people who provide healthcare services (e.g. doctors, nurses, pharmacists, etc.) and a 
patient or individual; who avails of said healthcare 


9.4.2.6.Actors 


Actors 


Actor name Actor type Actor Description Additional Information I d en t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Patient/ Participant A person who Natural person 
Individual avails of healthcare 
services 


Healthcare Participant A person or people Natural person or 
Provider who provide Legal entity 
healthcare services 
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9.4.2.7.Interaction between Actors and User Requirements 
9.4.2.8.Use case diagrams / tables 

9.4.2.9.Data Flow Diagram of Use Case 
9.4.2.10.Pre-conditions or requirements or assumptions 
9.4.2.11.Post-conditions 

9.4.2.12. Technical architecture of the use case (optional) 


9.4.2.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


9.4.2.14.Security and privacy 

9.4.2.15.Legal considerations (optional) 

9.4.2.16.Referenced standards and/or standardization committees in relation to this use case (optional) 

1 Sean Hogan et. al, IBM Institute for Business Value, “Healthcare rallies for blockchains: Keeping 


patients at the center", 11-06 2017, https://www-01.ibm.com/common/ssi/cgi-bin/ssialias? 
htmlfid=GBE03790USEN 








2 Franziska Boehm (University of Münster, Institute for Information, Telecommunication and Media 
Law, Germany), *A comparison between US and EU data protection legislation for law 
enforcement purposes", 08-10-2015, http://www.europarl.europa.eu/thinktank/en/document.html? 
reference=IPOL_STU(2015)536459 








9.4.2.17.Relations with other known use cases (optional) 

9.4.2.18.Smart contracts used (optional) 

9.4.2.19.Merit over traditional ledger 

9.4.2.20.Use case concerns, issues 

9.4.2.20.1.Migration of Existing Healthcare Data Records 

For the proposed use case there is a high possibility that existing healthcare data sets from multiple sources 
will have to be migrated to a blockchain solution. During this migration phase it should not be presumed that 
all existing healthcare data 1s errorless. As such a fit for purpose validation and verification process should be 


considered to ensure migrated healthcare data used to create a lifetime healthcare data record using blockchain 
technology is accurate. 


9.5. Smart manufacturing 
9.5.1.General 


Smart manufacturing is the systems and processes of manufacturing products utilizing advanced information 
and processing throughout the production life cycle to improve efficiency, speed, and quality. 


Blockchain/DLT can be used to collect and store information regarding each phase of production, such as 
component information for traceability, sensor and equipment data and logs to identify problems, supply chain 
and inventory information for managing production levels. It can also be used for sales and post-sales 
analyzation. A decentralized ledger allows each process in the production chain to operate independently and 
avoids the bottlenecks of a central server. Each process is able to get relevant real time information. The 
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transparency of blockchain/DLT allows the entire process from pre-production to post-production to be 
analysed for performance improvements, efficiency, potential problems. 


9.6. Intellectual Property Management 
9.6.1.General 

9.7. loT 

9.7.1.General 


IoT refers to the plethora of smart devices, objects, wearables, vehicles, buildings, machines, and electronics 
embedded with hardware and software, that connects to the Internet. These IoT devices communicate with 
servers and/or each other to provide a wide range of services and applications (e.g. monitoring sensor data, 
providing networking services, tracking object location, automating tasks, etc...). The processing, storage, and 
communications infrastructure required to maintain functionality increases in parallel with the increase in IoT 
devices and functions and features added to them. Traditional communication using a centralized, brokered 
model may not be able to provide the resource and functionality demands in the future. 


The decentralized, peer-to-peer networking used by blockchain/DLT can provide suitability for edge 
computing and machine-to-machine (M2M) communication for IoT devices to provide new services and 
functionality. It can also provide reliability and security as there is no central point for failures and malicious 
attacks, thus allowing devices to continue functioning uninterrupted. The immutability of blockchain/DLT 
assures that transactions are safe. Registering devices on the blockchain/DLT provides a method for device 
identification and authentication that can be used for communication, access, control, and updates. 


The increasing usage of IoT devices makes security and privacy a priority issue before people are willing to 
entrust their data to them. Limited resources on some IoT devices may require special blockchain/DLT 
schemes to work proficiently. 


9.8. Supply chain management 
9.8.1.General 


Supply chain management integrates the flow of information, goods, services, and capital across suppliers, 
manufacturers, distributors, and retailers. Traditional supply chain management systems are often proprietary 
and lack transparency, making it difficult to identify problems and inefficiencies in the supply chain. The use 
of blockchain/DLT in supply chain management makes the information transparent to all parties involved in 
the supply chain. Inventory and supply levels can be monitored to identify bottlenecks or where problems are 
in the supply chain. Goods can be tracked from origin of their raw materials through the production process 
and from shipment to receipt of the finished product and even beyond. Smart contracts can be used to 
automatically fulfil contracts and payments when each party's terms are met to eliminate delays and errors. 


9.8.2.Supply Chain Management and the use of Blockchain (This use case is needed to rewrite because 
of non-conformance to use case guidelines in some parts) 


9.8.2.1.Brief description 


In a global supply chain where US $4 trillion+ goods are shipped each year, there are ongoing initiatives to 
provide efficiencies and transparency to the many complex processes. The scale of global supply chains has 
led to a collaborative approach to new solutions, bringing together the world's largest companies and the 
newest start-up companies working with new technologies. The World Economic Forum estimates the 
opportunity and impact of reducing supply chain barriers to trade could increase global GDP by nearly 5% 
and trade by 15%. 


This Use Case considers where Blockchain is providing a new way to record provenance across complex 
supply chains, enabling more efficient trade, reduced fraud and access to trade finance. The use case for 
blockchain in Supply Chains across large dispersed industries has attracted much global attention from 
supermarket groceries to electricals, and for commodities from steel to diamonds. 
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9.8.2.2.Detailed description 


In this use case, we consider what specific attributes of blockchain are being applied to Supply Chain 
Management, and provide examples of current activity across multiple stakeholders and business sectors. 


The attributes of Blockchain and DLT for Supply Chain solutions include: 
e The creation of a digital asset on a blockchain (i.e. asset digitization). 


e An immutable record in the supply chain, which provides a trusted source and tracker, as the record 
cannot be changed 


* The ability for immutable records to be shared or have permissioned access to trusted parties e.g.: 
traders, customs and logistics. 


* The facility for Identity of People, Entities, Things and Processes across the complex global supply 
chain actors 


* Smart contracts to enable efficient record processing 
e Transparency across multiple stakeholders, goods, countries 
9.8.2.3.Scope and objectives 


The scope Use Case considers where Blockchain is providing a new way to record provenance across 
complex supply chains, enabling more efficient trade, reduced fraud and access to trade finance. 


The commercial, legal and social impact is highlighted by multiple studies: 


* The World Economic Forum estimates that educing supply chain barriers to trade could increase 
global GDP by nearly 5% and trade by 15% 


* IBM and Maersk report the global supply chain sees US$4 trillion* in goods shipped each year, 
where 8096 of goods are carried by the ocean shipping industry. The costs of administration and 
document processing is estimated to take up to 20% of the actual physical transportation costs. 

In this use case, we consider what specific attributes of blockchain are being applied to Supply Chain 
Management. In this way the objectives are to provide current examples of activity across multiple 
stakeholders and business sectors in creating a 'Supply Chain Trust Framework'. 

* The global scope of supply chains 


* The system could be agnostic to any particular blockchain and/or is inter-operational 


e The model has flexibility to accommodate and respect local and national laws and regulations 


9.8.2.4.Additional information 


This is additional information related to the use case, including a listing of potential economic and non- 
economic benefits. 


9.8.2.5.Context/Setting 
In this Use Case, we look at two contexts for 
* Logistics Management 


e Asset Management 
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The scale of global supply chains has led to a collaborative approach to solutions, bringing together the 
world’s largest companies and the newest start-up companies and technologies. 


9.8.2.5.1. Logistics Management 


Context: In 2018, Maersk and IBM announced their plan for a joint venture This builds on earlier 
pilots from 2016 which included DuPont, Dow Chemical, Tetra Pak, Port Houston, Rotterdam Port 
Community System Portbase, the Customs Administration of the Netherlands, U.S. Customs and 
Border Protection. New interest is reported from General Motors and Procter and Gamble Agility 
Logistics ? This use-case has been explored in detail by Professor Roman Beck? of the University of 
Copenhagen^ 


Objective: Applying blockchain to improve global trade and digitise supply chains. 
Use of Blockchain: The 2 main focus areas are: 


o Shipping information pipeline end-to-end supply chain visibility to enable all actors 
involved in managing a supply chain to securely and seamlessly exchange information about 
shipment events in real time. 


o Paperless Trade will digitize and automate paperwork filings by enabling end-users to 
securely submit, validate and approve documents across organizational boundaries, ultimately 
helping to reduce the time and cost for clearance and cargo movement. Blockchain-based 
smart contracts ensure all required approvals are in place, helping speed up approvals and 
reducing mistakes. 5 


Blockchain Unleashed: IBM Blockchain Blog Home Category v Contributors Aboutus Blockchain 


The case for a better way 


TODAY FUTURE 





Global Trade Digitization 










+ 4 ^ ^ ^ * + ^4 ^ 
--—----- i i 1 i i i i i 1 
* ! E ! * ! E ! * 
Forwarder E (©) e ' e H © ' @ 
^N į Exporter J Trucker + Rail + Forwarder | — Consignee 
Terminal Authority Carrier Terminal Authority Authority Carrier 


* Inconsistent information across organizational boundaries and “blind spots" 


throughout the supply chain hinder the efficient flow of goods 


* Complex, cumbersome, and costly peer-to-peer messaging 
* Manual, time-consuming, paper-based processes 


* Risk assessments often lack sufficient information; clearance processes 


subject to fraud 


* The administrative cost of handling a container shipment is comparable to 
the cost of the actual physical transport 


Source: 


* Fast, secure access to end-to-end supply chain information; single source 


ofthe truth 


* Verifiable authenticity and immutability of digital documents 

* Trusted cross-organizational workflows 

* Better risk assessments and fewer unnecessary interventions 

* Far lower administrative expenses and elimination of costs to move 


physical paper across international borders 





9.8.2.5.2.Asset Management 


9.8.2.5.2.1.High Value Commodities diamonds 
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Context: The global diamond industry is being challenged to provide more transparency with the help of 


blockchain, to address the issues of fraud, ethical sourcing and banking risks. 


Objective: Reduce risk and fraud for banks, insurers and open marketplaces that addresses all participants in the 


supply chain (e.g.: miners, suppliers, retailers and consumers) 
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Use of Blockchain: In 2015, Everledger started using blockchain to eliminate fraud and other corporate risks, 
by tracking the provenance of diamonds. As a contributor of the Hyperledger community, by 2017, Everledger 
announced? they had placed 1.6million diamonds on a blockchain, with digital records of attributes including 
the colour, carat, and certificate number. In 2018, DeBeers announced? it has researched a blockchain solution 
in response to increasing number of customers wanting guarantees diamonds had not been used to fund 
conflicts 10 


9.8.2.5.2.2. Agriculture 


Context: Australia's largest grain exporter, CBH trials blockchain tracking system with AgriDigital" 


Objective: Aim to reduce costs, deliver new revenue streams to growers, and provide better supply 
chain data to potential buyers for new Asian markets". 


Use of Blockchain: Explore the application of blockchain in agri-supply chains to provide 
provenance through full supply chain traceability from origin and document its quality. The pilot 
featured four different scenarios focusing on the creation of digital title and providing supply chain 
traceability’. The 2018 plan is to test executing the settlement of commodities on a blockchain by 
matching title transfer to payment in a single transaction. This includes creating digital title to 
commodities, removing double data entry, proving a clear chain of custody and supporting full 
traceability of commodities. 


Additional examples: In the UK, Provenance" is a start-up providing a blockchain based platform 
being used by over 200 major retailers and producers in the food and drinks industry to help prove 
the provenance of their product 


9.8.2.5.2.3.Global Food Supply 


Context: Nestlé, Unilever and Walmart!5 have established a collaboration with IBM!6 to explore how 
safety across the global food supply chain can benefit from blockchain technology. This builds on an 
earlier initiative with the Blockchain Food Safety Alliance in China!? 


Objective: For all participants in the supply chain (e.g.: growers, suppliers, retailers and consumers) 
to quickly be able to trace a contaminated product to its source and stem the spread of illnesses 


Use of Blockchain: Using the IBM platform to provide transparency by tracking a product from the 
farm to the retail shelf in seconds rather than days. Allows all participants to share information 
rapidly across a trusted network. 


9.8.2.5.2.4.Aerospace Parts management 


Context: Airbus? and Lufhanser are two of many aerospace companies looking to use blockchain for 
complex supply chains of aircraft components, and for a trust framework in large procurement 
processes. 


Objective: How can blockchain facilitate transparency is a complex global supply chain (e.g.: 
airlines, manufacturers, governments, consumers) where there is a high cost of trust, a slow process 
but time-sensitive interactions, compliance issues, high overhead cost for data reconciliation, and 
multiple parties that need to share data. 


Use of Blockchain: Airbus and SAP joined the Hyperledger project? where Airbus aims to test 
blockchain to track aircraft components for quality, provenance and compliance of components along 
the entire supply chain for maintenance?.  Lufthanser has created the ‘Blockchain for Aviation 
(BC4A)?! programme with a focus on MRO service providers (maintenance, repair and overhaul) to 
be able to review the entire maintenance cycle of a single component in its entirety. It reduces risk for 
MRO service providers who can provide verifiable documentation or identify their processes and 
provenance. 


There are multiple blockchain pilots for other potential applications for Supply Chain. There is a separate 
Use Case report for Trade Finance, that includes R3 Corda and TradeIX7, Ethereum and Barclays Bank? and 
IBM and Sainsburys”4 
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9.8.2.6.Actors 
This is a list of actors in the use case. 


The Actors in Supply Chain may have multiple roles as products are processed through a supply chain, for 
example a Supermarket chain may be both the Logistics importer, the producer and the end-customer. This 
guide provides high-level categories. 


Actors 


Actor name Actor type Actor Description Additional Information I d en t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Blockchain ^ Technology Actor who provides Examples: Legal entity 
platform provider a blockchain record 
provider ofa transaction, as IBM, Ethereum, 

a trusted source. 

This may be a large Everledger 

platform provider 

or new start-up firm Debeers 


AgriDigital 


Logistics: Actor who imports Examples: Natural person or 


or exports goods. legal entity 
Importer/ This includes large Maersk 
Exporter logistics companies 

or multiple smaller CBH Group 

traders 


Producer Farmer, Actor that grows Fairtrade farmers Natural person or 
manufacturer the crop, processes legal entity 
the grape for wine, 
manufacturers an 
engine part 


Customer Customer/Retailer Actor who sells/ Examples: Natural person or 
uses/consumes the legal entity 
end product Supermarket customer, 


Walmart, Nestle, 
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9.8.2.7.Interaction between Actors and User Requirements 
9.8.2.8.Use case diagrams / tables 
9.8.2.9.Data Flow Diagram of Use Case 
9.8.2.10.Pre-conditions or requirements or assumptions 
Assumptions include: 
* Adoption models such as government led initiatives for trusted supply chain and borders 


e  Off-chain storage: All use cases assume an integration with off-chain systems, from front-end devices 
through to off-chain storage and digital assets. 


e IoT integration: Blockchain will be able to interact and be future proof for multiple IoT assets, from 
biometrics on labels to packing cases. 


e Device agnostic: The ability for users to move beyond the mobile app, to multiple devices 

* Access: The existence of suitable open network access (internet via Wi-Fi, for instance) at logistics 
locations, but the system can employ communications in areas with low or intermittent network 
connections. 


9.8.2.11.Post-conditions 


With the use of the proposed systems, the seamless supply chain processes will offer efficiencies in time, 
reduce risk of provenance and minimize duplication of data. 


9.8.2.12. Technical architecture of the use case (optional) 


9.8.2.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.8.2.14.Security and privacy 
There are fundamental User principles and attributes required of the system: 


e The supply chain process has a mix of private and public access, based on permissioned or authorised 
access by relevant participants 


9.8.2.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 

9.8.2.16.Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.8.2.17.Relations with other known use cases (optional) 

9.8.2.18.Smart contracts used (optional) 

9.8.2.19.Merit over traditional ledger 


Blockchain offers specific attributes over a traditional ledger that reflects the shift from centralized to 
decentralized systems: 
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The attributes of Blockchain and DLT for Supply Chain solutions include: 


e The creation of a digital asset on a blockchain (i.e. asset digitization). 


e An immutable record in the supply chain, which provides a trusted source and tracker, as the record 
cannot be changed 


e The ability for immutable records to be shared or have permissioned access to trusted parties e.g.: 
traders, customs and logistics 


* Identity of People, Entities, Things and Processes across the complex global supply chain actors 
e Smart contracts to enable faster record processing 


e Transparency across multiple stakeholders, goods, countries 


9.8.2.20.Use case concerns, issues 


A User always has the option and control to permission and shares the data, subject to local laws or 
regulations 
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9.9. Energy 

9.9.1.General 

9.9.2.Energy distribution with the use of smart contracts 
9.9.2.1.Brief description 


Micro-generation promises to greatly contribute to the energy balance of the energy grid; however, so far, its 
market penetration is going slow due to the few, or not-existing, direct economic benefits end-users would 
enjoy by deploying an in-house micro-generation system. In this use case, taking advantage of the 
potentialities of blockchain technologies, we propose a solar energy production and distribution architecture 
using smart contracts, a particular distributed ledger paradigm, to support automatic energy exchanges and 
auctions, potentially enabling a new, open and more fruitful, under an end-user perspective, energy micro- 
generation market. 


9.9.2.2.Detailed description 
In our model, we assume a local grid where energy is produced and consumed in a limited geographical area, 


such as a local neighbourhood. Energy produced by a prosumer may be saved in the user’s local battery for 
later use or may be immediately injected in the local grid. An additional possibility is to have a common, 


© ISO 2017 — All rights reserved 
39 


central to the neighbourhood, battery shared as a temporary energy buffer. The model is divided in three 
layers: (a) the energy grid, (b) the middleware controller, and (c) the smart contract. 


When energy is injected in the grid a smart meter linked to each producer continuously measures how much 
energy has been injected in total. These smart meters, along with the software that handles their output, i.e. a 
middleware controller, are the input source for our smart contracts. After a predefined amount of energy has 
been injected to the grid, an Energy Coin is awarded to the corresponding prosumer. 


The middleware controller interconnects the grid with the smart contract since these systems cannot 
communicate directly with each other. As a result, the controller plays the role of invoking the smart contract 
on one end, and on the other receiving the readings from the grid, thus facilitating communication between the 
two entities. 


9.9.2.3.Scope and objectives 


The main aim of our model is to enable micro-grid prosumers to produce, consume and trade energy. In 
particular, they would be able to: 


* Release excess energy to the grid and receive virtual coins in return 
° [ransfer/Exchange the virtual coins 
* Redeem the virtual coins in exchange with energy 
* Enable prosumers to access the energy market 
9.9.2.4.A dditional information 
Details of this use case can be found in the paper: 


I. Kounelis, G. Steri, R. Giuliani, D. Geneiatakis, R. Neisse and I. Nai-Fovino, "Fostering consumers' energy 
market through smart contracts," 2017 International Conference in Energy and Sustainability in Small 
Developing Economies (ES2DE), Funchal, Portugal, 2017, pp. 1-6. doi: 10.1109/ES2DE.2017.8015343 


9.9.2.5.Context/Setting 


Micro-generation is the capacity for consumers to produce electrical energy in-house or in a local community. 
The concept of "market" indicates the possibility of trading the electricity that has been micro-generated 
among producers and consumers, where a user acting both as a producer and consumer is called a “prosumer”. 
Traditionally, this market has been served by pre-defined bilateral agreements between prosumers and retail 
energy suppliers. This means that until now, electricity-generating prosumers have not had real access to the 
energy market, which remains a privileged playing field for the institutionalised energy suppliers. This fact 
has, so far, heavily impacted on the real diffusion at large scale of micro-generation due to the limited 
economic advantages this energy generation approach would bring to the prosumers. 


Indeed, the main options considered so far by the technical literature, were completely centralised and their 
viability (under a prosumer perspective) was in general challenged as they introduce additional management 
fees and costs and assume the intervention of a trusted third party reducing once again the potential gains of 
end-users. New approaches should be developed enabling end-users to have free access to the energy market. 
In this context the advent of distributed ledgers, 1.e., blockchains, can be considered beneficial. 
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9.9.2.6.Actors 


Actor name Actor Actor Additional Information/ X Identity types(Natural 
type Description technology persons/Legal entities/ 
Things/Process) 


Energy The entity that Natural person/Things 
Producer produces energy 

and pushed it in 

the grid 


Energy The entity that Natural person/Things 
Consumer buys/consumes 

energy from the 

grid 


Controller Middleware entity  Web3 JavaScript Dapp API — Things/process 


that facilitates 
communication 
between the user 
and the smart 
contract 


Smart The application smart contract Process 
Contract logic that enables 

transactions of 

virtual energy 

coins 


Electrical Physical layer for 

Grid energy exchange 
(batteries, smart 
meters, inverters, 
etc.) 





9.9.2.7. Interaction between Actors and User Requirements 


9.9.2.8.Use case diagrams / tables 


The interactions of the main actors, as described in the previous section, can be seen in the use case diagram 
of Figure 1. Briefly, the energy producer gives energy to the grid which implies that energy coins are created 
at the smart contact and are sent to him. The energy consumer can request for energy at the smart contract 
which will result in having energy sent to him. Both actors can use the smart contract to transfer coins to other 
entities of the system. On the other side, the electrical grid represents the physical infrastructure which makes 
all energy exchanges feasible. Finally, the box in the middle represents the system processes, both on the 
smart contract and the controller level. 
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Figure 1 — Energy model use case 
9.9.2.9.Data flow diagram of use case 


The interactions between use case entities are the following: 


1 When energy is injected in the grid a smart meter linked to each producer continuously measures 
how much energy has been injected in total. 


i) The measurement is sent to the middleware controller which triggers the corresponding smart 
contract function. 


iii) The smart contract function issues the amount of energy coins that correspond to the energy 
injected. The coins are sent to the energy producer's address. 


iv) An energy consumer can purchase energy coins from the producer by different means (e.g., 
Bitcoin, Ether, Euro, etc.) 


v) When a consumer wants to purchase energy, he needs to send energy coins to a predefined smart 
contract address. 


vi) Once the coins are received, an event will be broadcasted to the network. Once the controller 
receives the event it will communicate with the grid and issue a command to release the amount 
of energy that corresponds to the number of virtual coins received to the consumer. 


vii) The smart meter will monitor the energy flow and will stop once the purchased energy is sent. 
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Figure 2 — Energy model proposal 
The diagram with all the interactions can be seen in Figure 2. 
9.9.2.10.Pre-conditions or requirements or assumptions 
We assume the existence of a local grid where energy is produced and consumed in a limited geographical 
area. The energy producers and consumers should be connected to a blockchain network (e.g., Ethereum). 
Moreover, the smart meters should be able to communicate with the middleware controller. 
9.9.2.11.Post-conditions 
With the use of the proposed system, energy accountability can be performed and mutual trust on the energy 
measurements is achieved. The measurements can be audited by any interested party without revealing 
personal data. 


9.9.2.12.Technical architecture of the use case (optional) 


9.9.2.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.9.2.14.Security and privacy 


The access of energy data should be protected appropriately as they can be used for identifying end users and 
their activities from their energy consumption. 


9.9.2.15.Legal considerations (optional) 


Legal Contracts, Legal Regulations, and Constraints 
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9.9.2.16.Referenced standards and/or standardization committees in relation to this use case (optional) 


This is a list of references used by this use case. 


9.9.2.17.Relations with other known use cases (optional) 

9.9.2.18.Smart contracts used 

The smart contract has the role of the record keeper, with the corresponding reward mechanism. Every time a 
user commits energy in the grid, the smart contract will issue coins that correspond to the energy produced 
and automatically send them to the energy producer. 

More specifically, the smart contract has a mint token function that takes as input two parameters: the address 
of the entity that has produced the coins and an integer that represents the number of energy coins to be 
issued. What this function does is to issue new coins and assign them directly to the indicated address. Once 
the energy producers are in possession of the coins they can circulate them freely according to their desires; 
they can choose to sell, use or exchange them. 

From the smart contract’s address, one can verify at any time the balance of any address, view the total supply 
in coins, view the smart contract’s name and symbol, view the smart contract’s owner, and follow live the 
transactions related to the smart contract that occur in the blockchain. The functions of the contract are 


viewable for everyone, but apart from the transfer function, i.e. the function to transfer coins from one user to 
another, are only executable by the contract’s owner. 


9.9.2.19.Merit over traditional ledger 
Enable users to access the energy market and exchange energy directly with other entities. 
9.9,2.20.Use case concerns, issues 


The middleware controller needs to be a trusted entity. 


9.9.3.Energy certificates of origin 
9.9.3.1.Brief description 
Blockchain enabled system that establishes a standard method for renewable energy generators and buyers of 


any size to trade, track, claim, and report green attributes of generation within and across certificate of origin 
markets, such as renewable energy certificates (RECs) and guarantees of origin (GOs). 


9.9.3.2.Detailed description 

End-to-end decentralized application enables any trusted renewable generator to sell green attributes peer to 
peer. Uses a simple, low-cost, standard approach across different global markets. Smart contract “checker” 
approves validity of data for generation. One digital asset created for each kWh generated, including: 
timestamp, GPS coordinate, asset type (wind, solar, etc.), asset owner ID, carbon displacement. Buyers 
purchase and retire certificates to claim green attributes. 

9.9.3.3.Scope and objectives 


The scope of this use case is to create a straightforward, end-to-end solution for generators and buyers with a 
user-friendly interface that covers the following key activities: 


1. Onboarding renewable energy generators, buyers, and reporting entities 
2. Uploading kWh generation data on an hourly basis 


3. Issuing kWh green attribute digital assets for validated kWh generation data 
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4. Buying, claiming, and retiring green attribute digital assets—with the option to automate this process 
to match energy consumption on an hourly basis 


5. Sending reports to regulatory bodies about generated renewable energy or claimed/retired green 
attribute digital assets 


9.9.3.4. Additional information 


This is additional information related to the use case, including a listing of potential economic and non- 
economic benefits. 


9.9.3.5.Context/Setting 


Renewable energy markets across the globe depend on a single instrument—certificates of origin, including 
but not limited to RECs and GOs—to provide verified proof of renewable generation, subsidize the cost of 
renewables, and empower consumers to financially support renewable generation and indicate their growing 
demand for renewables. By documenting how, where, when, and by whom each megawatt hour of renewables 
is generated, this blockchain application provides critical green attribute information for those who want to 
buy renewables and those who regulate compliance with renewable energy policy targets. 


9.9.3.6.Actors 


This is a list of actors in the use case. 


Actors 


Actor name Actor type Actor Description Additional Information/ I d e n t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Originator Originator A person Natural person or 
representing an legal entity 
organization, which 
generates 
renewable energy 


Renewable An asset generating 

Generating renewable Energy, 

Asset including the 
network enabled 
data logger 


Trading Trading platform A system which Process 
platform shows offers of 

certificates and 

makes them 

tradable 


Asset Administrator A person Natural person or 
registry responsible for the legal entity 
administrato onboarding process, 
r validating the 

information, that an 

asset is certified/ 

vetted before 

entering it into the 

asset registry 
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Field Service Technician A person authorized Natural person or 
Technician to install devices legal entity 

and software in the 

field at the 

Originator side and 

asset side 


Aggregation Aggregation A system Process 
Watchdog Watchdog component which 

monitors every data 

log entry 


Current Current A person, Natural person or 
Certificate Certificate Owner representative of legal entity 
Owner the organization 

which has current 

ownership of a 

certificate 


Certificate Certificate buyer A person, Natural person or 
buyer representative of legal entity 

the organization 

which will buy the 

certificate 


Certificate Certificate System component, Process 
registry registry keeping track of 

current ownership 

and metadata of a 

certificate 


Trading Trading platform External pre- Process 
platform existing Trading 

Platform, a system 

which shows offers 

of certificates and 

makes them 

tradable 
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9.9.3.7.Interaction between Actors and User Requirements 


9.9.3.8.Use case diagrams / tables 








& Generation asset @ As each KWh is Buyer buys a certain D After a buyer claims Certificates about 
is permissioned generated, oracles or quantity of KWh from KWh digital assets, the purchased KWh can 
to write data / meters linked to generators—with the buyer receives a be used for 
modify generation assets option to automate these certificate and the reporting needs— 
blockchain after automatically update purchases through smart KWh are instantly/ with the option to 
onboarding blockchain with newly contracts in real-time automatically retired automate reporting 
process issued digital KWh assets 


9.9.3.9.Data Flow Diagram of Use Case 

9.9.3.10.Pre-conditions or requirements or assumptions 

There is demand for this application among buyers of renewable energy. 
The renewable generation asset has been certified/vetted. 

The users and assets are registered in the asset registry. 


Power has been generated and respective data sets of this have been created, and the threshold of 1 kWh has 
been reached. 


9.9.3.11.Post-conditions 


Buyers purchase and retire certificates to claim green attributes. 
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9.9.3.12. Technical architecture of the use case (optional) 
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kWh Tag 
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9.9.3.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


EWF 
Light 
Client 





kWh tracker 











Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.9.3.14.Security and privacy 

Data would be extremely difficult to tamper with due to a combination of strong cryptography, the 
interdependent relationship between each block of data, and distributed consensus. Also, smart contracts can 
eliminate the risk of double-counting by automating certificate retirement. 

9.9.3.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 

9.9.3.16.Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.9.3.17.Relations with other known use cases (optional) 

9.9.3.18.Smart contracts used (optional) 

9.9.3.19.Merit over traditional ledger 

9.9,3.20.Use case concerns, issues 


There are too many markets, each with unique characteristics, which presents challenges for customers buying 
certificates in multiple markets. 
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9.10.Government and public sector 
9.10.1.General 

9.10.2.Smart inheritance proceeding 
9.10.2.1.Brief description 


This use case describes a public service implementing statutory and wilful inheritance on blockchain, using 
smart contracts. 


9.10.2.2.Detailed description 


The use case describes the process of inheritance proceeding executed automatically on the event of death of a 
person. The proceeding is based on the execution of smart contract recorded on a blockchain which 
implements statutory inheritance or wilful inheritance, provided that authenticated Testator explicitly entered 
her last will to the contract. 


The basic part of this use case is creation of a default inheritance contract. Default inheritance contract is 
created automatically upon a birth of a person as a part of her personal record in Civil Status Office. This 
default contract (i) implements statutory inheritance rules, meaning it follows provisions of the inheritance 
law with regards to the order of inheritance, the shares and the set of entitled hairs; (11) tracks the actual status 
of a person along her life with respect to her acting in the capacity of Testator (for example number of 
children, changes of civil status that impact the allocation of Testator’s estate and/or set of statutory heirs); 
(iii) tracks the actual state of Testator’s estate. 


In the event of effectively identified death of Testator the statutory inheritance smart contract is initiated and 
self-executed without a need of interference, unless the Testator introduced her last will to the contract 
changing it to wilful inheritance. 


The inputs for statutory inheritance contract are: 


1. Actual set of statutory heirs to Testator, based on the personal records from Civil Status Office 
composed from entries from births registry, marriage registry and deaths registry. 


2. Actual state of Testator’s estate, based on the records from Land registry and (facultative) Financial 
assets registry. 


In case of wilful inheritance contract Testator introduces changes to the contract with respect to input (1) 
above. She may change the set of heirs (appoint a different person or institution) and the allocation of her 
estate among heirs. She may also set an allocation of her transferable inheritance rights which will become 
executable in future in the event of death of other persons. 


Smart contract is executed upon notification of Testator’s death from deaths registry, digitally signed with a 
pair of private and public keys of the Civil Status Office. 


In the case of existence of any transferable inheritance rights, which shall become executable in the event of 
death of another person and after the death of Testator (bringing new items to the estate after her death), smart 
contract can be again activated. The activation condition is based on arrival of new objects to the Testator’s 
estate. The contract applies statutory or wilful inheritance rules to these new parts of estate. 


The outcome of the smart contract is a set of authenticated instructions to be executed by respective public 
registries. This includes updating personal records of heirs in Civil Status Office and title records in Land 
registry and records in Financial assets registry. If inheritance creates any tax obligations on the part of any 
heir, the execution of such obligation should be handled by tax registry based on timestamped record from 
Land and Financial assets registries (outside of the scope of this use case). 
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9.10.2.3.Scope and objectives 


The objective of this use case is to show how a person can effectively transfer her estate in the event of death 
by using irreversible, transparent, secured and timestamped automated smart contract. The underlying 
blockchain technology assures integrity of the last will and dramatically lowers transaction costs of 
inheritance proceeding as well as reduces fraud and legal disputes. 


9.10.2.4.Additional information 


Initially the service could be applied to the simplest cases where the heirs are close relatives (children, spouse) 
or wilful inheritance where Testator has no statutory heirs and hence no objections can be made to her last 
will. This type of situations constitute vast majority of cases, hence their automated execution would already 
bring substantial gains. The proposed use-case offers a number of benefits in comparison to the current state- 
of-art: 


(1) gains on fixed and variable costs of inheritance proceedings and unlocking qualified human resources, 


(2) huge time reduction of proceedings, resulting in minimization of time when the asset is blocked from 
trade or use as collateral, 


(3) elimination of fraud behaviour and extortions based on false last will, 
(4) elimination of court battles resulted from putting an integrity of a will into question, 
(5) efficient tax collection and increased tax base 


This use case might be extended from inheritance to more general management of wealth in case of different 
life events (not only death). For example a person might indicate in the contract, that in case of becoming 
permanently unconscious as a result of an accident, a certain part of her liquid assets should be secured for a 
medical treatment and rehabilitation. The execution condition could be initiated in this case by a trusteed 
person such as general practitioner. 


Inclusion of financial assets as a part of inheritable estate is challenging due to privacy reasons and 
confidentiality of banking information. Yet it is not impossible. The service could be initially restricted only to 
real estate property and registered financial assess. 


9.10.2.5.Context/Setting 


This use case belongs to a public sector domain and describes a government-to-citizen service. It is worth 
noting that a number of blockchain start-ups are working on similar solutions based on smart contract for 
token wallets, which currently are not considered inheritable assets. On the other hand few countries progress 
with putting selected registers on blockchain. This are the milestones for operation of smart contract that 
essentially uses inputs from several different registries and produces outputs which are to be integrated back 
there. 
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9.10.2.6.Actors 


Actor name 


Testator 


Lawful Heir 


Willful Heir 


Civil Status 
Office 


Land 
Registry 


Financial 
Assets 
Registry 
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Actor type 


individual 


individual 


individual/ 
institution 


institution 


institution 


institution 


Actors 


Actor Description 


An identifiable 
physical person 
who possesses 
estate (such as 
property or 
financial assets) 
and transferable 
inheritance rights 
which shall become 
executable in future 


A physical 
identifiable person 
recognized as heir 
by law 


A physical 
identifiable person 
or legal entity 
indicated as heir in 
the last will of 
Testator 


An entity 
maintaining death 
and birth registry 
and marriage 
registry on 
blockchain 


An entity 
maintaining land 
registry on 
blockchain 


An entity 
maintaining 
financial assets 
registry of physical 
persons on 
blockchain 


Additional Information/ I d e n t i t y 


types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Natural person 


Natural person 


Natural person or 


legal entity 


Legal entity 


Legal entity 


Legal entity 
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9.10.2.7.Use case diagrams / tables 














Figure 3 Inheritance flow 

9.10.2.8.Pre-conditions or requirements or assumptions 
Assumptions: 

1. Effective land registry system on blockchain 

2. Effective death and birth registry on blockchain 

3. Effective marriage registry on blockchain 

4. Effective financial assets registry on blockchain (facultative) 
Records from those 4 registries are inputs to automated inheritance smart contract 

5. Government-issued electronic identification with digital signature and corresponding infrastructure 
Pre-conditions: 


1. Testator authenticated to introduce changes to the default inheritance contact (i.e. shift from statutory 
to wilful mode) with private/public key infrastructure 


2. Wilful heirs' identities verified with private/public key infrastructure 
3. Each input record to the contract digitally signed by registry 
9.10.2.9.Post-conditions 


The execution phase ends after the contract agent verifies that the appropriate transfers to the heirs have been 
executed, signed by them and by the Land registry and registered on a blockchain. 
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The contract is idle until another initiation condition occurs that is when positive balance of Estate occurs (for 
example Testator received inheritance after his death). 


9.10.2.10. Technical architecture of the use case (optional) 


9.10.2.11.General implementation considerations: conformity aspects and critical requirements 
(optional) 


9.10.2.12.Security and privacy 
This use case involves complex management of privacy and has high security requirements. 


In particular the Testator might want to inform or not (some of) her heirs about the fact that she has introduced 
last will amendments to the inheritance contracts. 


It also involves dealing with financial assets, part of which might be subject to banking confidentiality. In such 
case it must not be disclosed to the public bodies. By using hashing functions blockchain seems perfectly 
fitted with this objective. 


Given that entering births or deaths data requires human intervention errors cannot be entirely ruled out. 
Hence a dispute resolution mechanism must be in place to correct for those errors. 


9.10.2.13.Legal considerations (optional) 

Given that inheritance 1s subject to state governance and specific local regulations but the real estate (as well 
as financial assets) can be freely traded in a certain jurisdiction, the solution to this use case must offer 
scalability and interoperability of basic infrastructure solutions, such as electronic identities. 
9.10.2.14.Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.10.2.15.Relations with other known use cases (optional) 

As indicated in pre-conditions, this use case 1s related to operation of at least several other registries on 
blockchain. Integration of timestamped messages from those registries is essential for smooth operation of 
smart inheritance proceeding. 

9.10.2.16.Smart contracts used (optional) 

Yes. Smart contracts are the core technology for automated inheritance proceeding as its execution is 
conditioned on the event of death or other initiation condition (in principle some else's death which affects the 
estate balance of Testator post mortem) 

9.10.2.17.Smart contracts used (optional) 

Described in Additional Information section 6.1.4 


9.10.2.18.Use case concerns, issues 


Security, scalability, cross country interoperability. 
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9.11.Real Estate 
9.11.1.General 


9.11.2.Title registry system using blockchain land ledger (This use case is needed to rewrite because of 
non-conformance to use case guidelines in some parts) 


9.11.3. 
9.11.3.1.Brief description 


There are several notable blockchain real estate pilot programs being developed. The prominent ones are 
Republic of Georgia and one in Sweden and in USA. Its implementation will significantly speed up full 
coverage of the country with high quality registration and cadastral data, which is a prerequisite for 
sustainable land administration system and land market development. 


9.11.3.2. Detailed description 

Georgia and Sweden use a title registry system, where a property changes ownership by a government official 
updating the land ledger to reflect the new owner. The government performs the conveyance between the 
parties. In contrast, (most of) the US uses the deed registration system where the seller transfers ownership of 


the property directly to the buyer using a deed. In a separate, optional step, the buyer may choose to publish 
this deed in a county clerk / recorder's office. 


The pilot program in Cook County, USA was a collaborative, volunteer effort, with talented individuals and 
organizations who represented public and private stakeholders. Besides velox.RE, these participants included: 


— Lewis Cohen, a partner at international law firm Hogan Lovells 

— Chuck Thompson, Founder of Blockchain Consulting and legal advisor to velox.RE 

— Leaders from The International Blockchain Real Estate Association (IBREA) 

— Cook County Recorder of Deeds (CCRD) 

— Two Chicago-based pro bono counsel from law firm Goldberg Kohn represented CCRD 


— Others from title insurance, notaries public, and technology lent their expertise for specific issue. 


9.11.3.3.Scope and objectives 


Land Registration State Project National Agency of Public Registry (NAPR) under the Ministry of Justice of 
Georgia, is a land administration authority being responsible for registration of immovable property rights and 
cadastral database in Georgia. 


The state project - reform removes barriers to land registration and allows citizens to register land easily and 
free-of-charge. It offers simplified procedures concerning legalization of land ownership rights, addresses the 
problem of “overlapping of land boundaries”, and introduces alternative dispute resolution mechanism — 
mediation. The enquiry and collection of the needed documents from other administrative authorities are done 
by NAPR. All services within the reform are free for citizens, including cadastral survey. Consequently, it 
drastically increases accessibility of registration service to entire population of Georgia. 
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9.11.3.4.Additional information 
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Figure 4 — Problems in real estate management ( Mats Snäll, Head of Development of Real Estate 
Registration, at the Swedish Land Registry) 
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The above figure clearly states the several steps in the real estate management. 
9.11.3.5.Context/Setting 


A registrar works only in one program and uses other systems like web service, which is necessary for 
property registration process. Exhaustive information on land registration reform is provided on the official 
website of NAPR. Publicity of all data ensures operational transparency and engagement of private owners. 
The 4-month statistical data shows a sharp increase of registration number and interest of citizens is growing 
daily. Up to date, over 90 thousand applications have been filed for land registration. It is expected to receive 
approximately 360,000 applications per year. 


9.11.3.6.Actors 


Actors 


Actorname Actor type Actor Description Additional Information/ I d e n t i t y 
technology types(Natural 


persons/Legal 
entities/Things/ 
Process) 





In order to simplify operating procedure next systems were integrated with immovable property registry (see 
Figure 4): 
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Figure 5 — Integration of several systems into immovable property register. 


Electronic Management System (EMS) 


Visit Planner (with Notary) 


Bauer of Technical Inventory (BTI) 


National Agency of State Property (NASP) 


Call Back — System for Hotline of Public Service Hall 


9.11.3.7.Interaction between Actors and User Requirements 


9.11.3.8.Use case diagrams/tables 


In case of USA the existing use case data can be referenced as follows : 
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Existing Real Estate Ecosystem vElox.RE 





Function 

Payment or currency 
Escrow 

Property Search 

Title Search 

Public Record of Title 
Conveyance 
Contracts 

Due diligence 
Property Identification 
Crowdfunding 
Mortgage tracking 





Proprietary 
software or 
closed system? 





Siloed 
Data? 





Technology 

Wire transfer or check 
Wire transfer, Web 
Paper, PDFs, Web 
Paper, PDFs, Web 
Paper, PDFs, Web 


Paper, PDFs, Web 

Microsoft Word, DocuSign 
Microsoft Excel, PDFs, & Web 
Meets and bounds, addresses 
Database, Web, wire transfer 
Database, Web 





3rd Party Needed To Complete Function 


Bank 


Bank, escrow (And title) company 


LoopNet, Zillow, NAR 
Title Companies & government 
Government 


Escrow & title company or attorney 


Attorney 

Broker, 3rd party vendors 
Cadasatre or tax assesors 
Banks & crowdfunding company 
MERS 
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9.11.3.9.Data Flow Diagram of Use Case 


9.11.3.10.Pre-conditions or requirements or assumptions 


9.11.3.11.Post-conditions 


9.11.3.12. Technical architecture of the use case (optional) 


The whole process involves the following steps: 


1) PDF extract is generated at registrar's desktop client application and is sent to database; 


2) Db2sign service takes new receipts from database, makes some adjustments to a file to get it ready 
for signing. At last sends file to digital signature service. 


3) Digital signature service makes several steps to make a valid signature: 


a. 


b. 


e. 


f. 


Generates hash of PDF file; 

Sends it to HSM, because there is no way to read private key from HSM; 

HSM makes a digital signature and returns signature data; 

Signature is put in PDF file and sent to Certificate Authority for OCSP check (The Online 
Certificate Status Protocol) to check certificate validation status; 


CA also makes a timestamp on a file (required by Georgian law). 


4) Signed PDF file is sent to blob storage, where it is saved permanently. On blob storage files are 
immutable, they can’t be deleted or edited. 


5) Bitcoin gateway makes transaction to Bitcoin blockchain, the process consists of following steps: 


a. 


b. 


Gateway reads the newly signed files from blob storage and generates its hash; 
A new bitcoin transaction object is created that contains files hash; 
The transaction is sent to Bitcoin network; 


After transaction is validated by blockchain its status and meta information is sent to 
application Oracle database, from database all document flow is observed. The status 
information from all steps is available from single point. Eventually, the extract file is 
protected with organisational seal (that has a legal power) and its existence can be proofed by 
anybody using Bitcoin blockchain. Thus there is no technical or any other way to alter the 
final result of registration. 
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Figure 6 —NAPR land registration implementation on Bitcoin network. 


9.11.3.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


9.11.3.14.Security and privacy 


National Agency of Public Registry is a property registering authority in Georgia with one of the most 
advanced and experienced IT Department providing its service not only NAPR but to other government 
agencies as well. It is critical for NAPR to ensure protection of the data. To guarantee data security and 
protection, new technologies and possibilities are researched and integrated in existing solutions. One of such 
solution is Bitcoin blockchain. 


Bitcoin’s blockchain is the best security store ever created by mankind. Besides it is distributed and 
transparent, anybody can validate transactions and the risk of data altering is insignificant. As new blocks are 
added to blockchain, its security strengthens. There is no practical way to alter even one transaction that was 
made an hour ago without huge financial investment. 


The extracts published on the official NAPR website are legal documents and it is especially important for 
NAPR to secure the system from malicious use and social engineering attack. Considering the responsibility 
of NAPR for protection of the documents, an organizational signature service was created and introduced at 
NAPR. Upon generation a new extract from any service, a PDF file is sent to signature service. The service 
keeps keys in a special Hardware Security Module device certified by FIPS 140 Level 2 and Common 
Criteria. HSM guarantees that no one will be able to dump NAPR public keys to generate fake receipts. 


The signed PDF can be validated offline. But public key signatures require trusted third party that will act as 
Certificate Authority. So all files are protected as long as CA is protected and trusted. To make the NAPR 
registration system even more trustful and useful, the digitally signed files are timestamped using Bitcoin 
blockchain. A hash of a file is sent as bitcoin transaction that will be permanently registered in blockchain. 


9.11.3.15.Legal considerations (optional) 


The state project of land registration is underpinned by appropriate legislative framework and technical 
support. The new legal framework has introduced efficient and effective legal mechanisms for solution of the 
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registration related problems and has fully encompassed necessary legal and procedural aspects for 
simplification of land ownership registration. 


9.11.3.16.Referenced standards and/or standardization committees in relation to this use case (optional) 


9.11.3.17.Relations with other known use cases (optional) 


9.11.3.18.Smart contracts used (optional) 


Step 2. 


Step 3. 


Step 4. 
Step 5. 


Step 6. 


Cities such as Chicago, Dubai, Rotterdam and Toronto, states such as Arizona, Delaware, Hawaii and 
Illinois, and countries such as Australia, Estonia, Georgia, Ukraine, Singapore and Sweden are taking 
active steps to support and develop blockchain databases and smart contract applications 


Sweden is perhaps the first country to implement smart contracts in real estate. There has been 
unconfirmed use case of smart contracts in real estate in Georgia. It is considered as experimental 
phase of the use case of smart contract 


While another use case that closely resembles smart contract is the one developed in USA (IBREA) 


Summary of velox.RE conveyance and recording system. 


. The property owner creates a blockchain title with velox. RE. This is a Bitcoin Colored 


Coin. The metadata field of the colored contains: 
o Grantor's name 
o Property legal description, Property Index Number, and common address 
o May also contain specific rights or (i) exceptions or reservations, such as 
encumbrances and (ii) a habendum clause. 


When the Grantor wants to convey his property, velox. RE creates a colored coin 
transaction. The metadata field of this transaction will include granting language, the 
name of the Grantee, and the type of deed. 


Grantee and Grantor meet at a closing table and establish their identity to the 
satisfaction of a notary. (Alternatively, the Grantee and Grantor may choose to use a 
Virginia-based eNotary via video conference). 


Grantee and Grantor select the property to be conveyed on the velox.RE platform and 
review the legal description of that property to ensure accuracy (including the presence 
or absence of any applicable exceptions or reservations and/or any habendum 
clause(s)). 


Grantee and Grantor ensure that the granting clause is accurate (i.e., that it properly 
states the consideration being transferred for the property identified in Step 1). Once 
confirmed, Grantee and Grantor electronically sign the deed by means of their Bitcoin 
ECDSA keys (or other acceptable digital signature). In this case, electronic signature 
by the Grantee will serve as proof of acceptance. 


The Notary notarizes the deed. 


The Grantor executes the conveyance by sending the colored coin to the Grantee. The 
colored coin transaction records the transfer on the Bitcoin network. This is the 
conveyance. 


The velox. RE system provides a simple method of printing a "paper" version of the 
blockchain deed —i.e., a deed that looks identical to that which a recorder would 
typically receive, albeit with digital signatures—which satisfies various states' 
requirements (e.g., Illinois) relating to the acceptance of paper deeds vs. electronic 
deeds. 


This document will include the Bitcoin Colored Coin transaction information, including: 
Transaction ID, transaction hash, block height, and timestamp. A QR code will link to 
either the colored coin transaction and / or a velox. RE page. This "paper" version can 
be recorded at the county recorder's office or possibly submitted electronically. 
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9.11.3.19.Merit over traditional ledger 
9.11.3.20.Use case concerns, issues 
This fragmentation and centralization produces the following ten pain points: 
— liquid assets / cumbersome title transfer 
— Slow price discovery 
— Expensive Due diligence 
— Incomplete and insecure property data 
— High transaction costs 
— Unnecessary third parties 
—  Non-interoperable and proprietary software 
— Legal inconsistencies 
— Fraud 
— Haphazard mortgage tracking 
9.11.3.21.References 
— _https://www.linkedin.com/pulse/permissionless-real-estate-title-transfers-bitcoin-lifthrasir-mred 
— _http://eulis.eu/uploads/slideshow/7.HenrikHjelteChromaWayBratislavaConferencecompressed_.pdf 


— http://www.eurocadastre.org/eng/sk_presidency2016.html 


9.11.4.Land Development Pipeline (This use case is needed to rewrite because of non-conformance to 
use case guidelines in some parts) 


9.11.4.1.Brief description 


Land is one of a country's most valuable assets. Land information, the digital representation of that land, is 
primarily maintained through a cadastre — the record of land ownership. 


9.11.4.2.Detailed description 


Land is one of a country's most valuable assets, from environmental, economic and societal perspectives. Its 
development and administration are complex processes involving multiple participants and iterative 
workflows. 


Land information, the digital representation of our land, is primarily maintained through the cadastre (the 
record of land ownership). For historical and practical reasons, in the case of NSW, the cadastre is basically 
represented in two ways: 


— The Titles Register: contains effectively ~4.5 million individual records, one for each land title 
(parcel); and 


— The Map Base: effectively a single seamless map base depicting the location and extent of all ~4.5 
million parcels. 


The Titles Register is specifically designed to focus on transactions: 
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— the creation and deletion of land parcels, Note 1, and 
— the transfer of title to land parcels between individuals and/or companies. 
NOTE! The creation of one or more new parcels from a parent parcel requires the deletion of the parent parcel 


Titles and the titling system are fundamental to the economy and society. In the case of NSW, more than two 
thirds of houses and small businesses are secured against title, making it a key financial instrument. 


9.11.4.3.Scope and objectives 


9.11.4.4. Additional information 

There is now increasing interest in information derived from and measuring land development processes. 

In NSW, the property sector is the largest industry sector at ~AUD65 billion and employing ~300,000 people. 
The property development pipeline is lengthy, complex, and involves multiple participants such as, state and 
local governments, developers, engineers, water, energy and telecommunications utilities. 

Delays are costly, as much of the development process is financed through borrowing. 


— Having the ability, at all times, to understand exactly what stage a development plan is at is crucial. 


— Having a common understanding, by all participants, is even more crucial, as the process involves 
several hand-offs, some iterative, between participants. 


— Having a system's level understanding of the overall stocks and flows of land is fundamental for 
strategic planning and infrastructure delivery. 


For these reasons, a system that securely versions development plans, documenting each progress step and 
incremental change, is becoming highly desirable. Blockchain and distributed ledgers may be well suited for 
meeting these requirements. 


9.11.4.5.Context/Setting 

This is a brief description of the context/setting/industry surrounding the use case. 

Use case vertical application field/domain: e.g. financial services, manufacturing... 

Use case vertical subdomains: e.g. cryptocurrency, mutual funds... 

Use case horizontal activity: e.g. asset management, notarization... 

In this use case example for NSW, the Titles System provides a highly secure and robust titling system, 
effectively guaranteeing title, serving the needs of the community and industry well. The level of fraud is 
extremely low. 

The NSW Titles System is based on Torrens Title and is a system of land registration. In the Torrens system a 
register of land holdings is maintained by the state and thus guarantees an indefeasible title to those included 
in the register. Land ownership is transferred through registration of the title instead of through a deed. The 
Torrens Title System simplifies land transactions and to certifies the ownership of an absolute title to the real 


property. The system is widely used in countries that were historically influenced Britain, especially those in 
the Commonwealth of Nations.[1] 
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9.11.4.6.Actors 


Actors 


Actor name Actor type Actor Description Additional Information I d e n t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


LGA Government registration / tax Legal entity 
collection 


Owners Individuals or title purchasers Natural person or 
Companies legal entity 


Utilities Infrastructure lifeline Legal entity 
Providers infrastructure 


Industry Companies providing a service Legal entity 
to/using the system 





9.11.4.7.Interaction between Actors and User Requirements 
Recording each instance of a parcel as it goes through the key points of development means close 
coordination and streamlining of the process, allowing each participant to act with confidence on authoritative 
information available to all. Once the plan is registered the use base for the information extends to include the 
public and broader industry sectors. 
In the case of NSW, the titling system only covers two milestone stages in the process, 

— creation/deletion, and 

— transfer of titles 
These stages are shown in Instances 1.0 and 2.0 in Figure 1. 
9.11.4.8.Use case diagrams / tables 
9.11.4.9.Data Flow Diagram of Use Case 


Figure 1 shows the land parcel lifecycle versioning flow of the current title and registration system. 
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Land parcel lifecycle versioning 
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Figure 1 — Flow Diagram 


9.11.4.10.Pre-conditions or requirements or assumptions 


Blockchain, or a similar capability, is potentially well suited to documenting and distributing property 
development information, and providing an authoritative source of information for the broad range of 
participants. 


9.11.4.11.Post-conditions 


The use of Blockchain technology to manage and disseminate authoritative property information could realise 
significant savings compared to the alternate development of a centralised system. It could also simplify the 
complex data management and governance arrangements that would be necessary to consolidate property 
information currently managed across a broad range of participants. 


9.11.4.12.Technical architecture of the use case (optional) 


9.11.4.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 
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9.11.4.14.Security and privacy 

9.11.4.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 

9.11.4.16.Referenced standards and/or standardization committees in relation to this use case (optional) 
[1] Torrens title. Available at < https://en.wikipedia.org/wiki/Torrens_title> 

9.11.4.17.Relations with other known use cases (optional) 

9.11.4.18.Smart contracts used (optional) 

9.11.4.19.Merit over traditional ledger 

While there are a number of international examples of title registries investigating the use of blockchain 
technology to more securely manage land ownership, this concept could be extended to encapsulate the 
broader property development process prior to and post registration, without interfering with the Torrens Title 
system. 


The capabilities of Blockchain technology could provide the following benefits: 


— Secure digital identification of participants and transparency of electronic approvals (by private 
certifiers, Councils, utilities, LPI, etc.) 


— Eliminate the use of fraudulent approval and insurance certificates 


— Enforcement of development conditions of consent, workflows and other regulatory 
requirements 


— Automatic management of development warranty periods, release of security deposits or bonds 
and settlements 


9.11.4.20.Use case concerns, issues 

9.12.Others 

9.12.1.General 

9.12.2.Smart contracts for data accountability and provenance tracking 
9.12.2.1.Brief description 


Smart contracts can be used to track data provenance and encode usage control policies regulating the access 
and usage (e.g., redistribution) of subject's data by controller and processors. 


9.12.2.2.Detailed description 


Data protection regulation in some jurisdiction imposes data protection requirements on data controllers and 
processors with respect to the processing of residents’ data. These requirements consist of a single set of rules 
that have binding legal status and should be enforced. In light of these requirements, this use case proposes the 
use of a blockchain-based approach to support data accountability and provenance tracking. This approach 
relies on the use of publicly auditable smart contracts deployed in a blockchain that increase the transparency 
with respect to the access and usage of data. Smart contracts can be used to encode data usage policies and 
provenance tracking information in a privacy-friendly way. 


9.12.2.3.Scope and objectives 


The scope is data accountability and provenance tracking using smart contracts when personal data is 
provided to service providers (data controllers and processors). The objective is to improve transparency and 
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auditability from a data subject point of view, allowing for blockchain-based informed consent and 
withdrawing. 


9.12.2.4. Additional information 


Details are in the academic paper Neisse et al. “A Blockchain-based Approach for Data Accountability and 
Provenance Tracking”, published in the ARES 2017 conference. 


9.12.2.5.Context/Setting 


The use case applies in any context where personal data about a subject is accessed by entities playing the role 
of a data controller or data processor. 


9.12.2.6.Actors 


Actors 


Actor name Actor type Actor Description Additional Information/ I d e n t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Data Subject Human user Owner of the data Legal entity 


Data Service provider Entity accessing Legal entity 
Controller data in order to 
provide service 


Data Service provider Entity processing Legal entity 
Processor data on behalf of 
the data controller 





9.12.2.7.Interaction between Actors and User Requirements 


9.12.2.8.Use case diagrams / tables 


The following figure shows the sequence diagram of the interactions between the entities and contracts. The 
subject subscribes with the data controller, creates the custom contract for this controller regulating the use of 
his/her data, and transfers the data to the controller. For each new established contract, the subject uses a new 
blockchain address to prevent linkability of the contracts established with each controller, requiring the 
subject to maintain a list of all addresses used and the respective nonce established with each controller or 
processor. After creating the contract, the subject transfers the data to the controller. 
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Figure 7 — Sequence diagram of use case interactions 
9.12.2.9.Data Flow Diagram of Use Case 
9.12.2.10.Pre-conditions or requirements or assumptions 


Subjects provide data to controllers and processors and have no auditable way of verifying how their data is 
being processed, stored, and redistributed. In case of privacy violations reported by subjects controllers and 
processors should be able to prove the data is stored and processed according to the subjects’ privacy 
requirements. 


9.12.2.11.Post-conditions 


Smart contracts can be used as an auditable way of encoding data provenance information and privacy 
requirements to enable subjects to evaluate who has accessed their data and the conditions for storage, 
processing, and redistribution of the data. In case subjects believe their privacy requirements are not being 
fulfilled they can revoke data access and usage rights using the blockchain. This provides a mechanism for 
legal compliance in the face of a data protection Regulation. Since in public blockchains the smart contracts 
are readable by anyone the data provenance and accountability information should be encoded in a privacy 
friendly way. 


9.12.2.12. Technical architecture of the use case 


The following figure presents the high-level architecture of the data accountability and provenance tracking 
model proposed in this use case. In this architecture, three main entities are depicted as the following 
terminology: the Data Subject, the Data Controller, and the Data Processor. When the subject subscribes with 
a controller, which is typically the role of a service provider, it creates a policy based Data Usage Contract 
specifying constraints on the usage and redistribution of any data obtained explicitly or implicitly by the 
controller. Explicit data is any data provided directly through interactions with the subject such as the e-mail 
addresses or birth date. Implicit data 1s any data acquired automatically, for example, sensor data from IoT 
devices in the environment surrounding the subject, data acquired by apps installed in mobile devices, or even 
server log files registering details of the network interactions between subject and controller services (e.g., IP 
addresses). The contract in this model acts as a data provenance tracker, policy evaluation entity, and event 
logger that allow the subject to easily check all data transfers and usage transactions providing assurance that 
only transactions conforming to the contract policies are authorized and registered in the blockchain. 
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Figure 8 — Architecture 


9.12.2.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.12.2.14.Security and privacy 

Privacy issues very relevant since fingerprints of the personal data and the usage control policies are stored in 
a public blockchain. The use case proposes a privacy-friendly way of encoding both data and policies in a way 
that is still meaningful for auditability purposes. The only thing that can be learned is the structure of the 
policy specified by data subjects and no details about the data or restricted activities that can be performed by 
data processors and controllers. 

9.12.2.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 

9.12.2.16. Referenced standards and/or standardization committees in relation to this use case (optional) 
This is a list of references used by this use case. 

9.12.2.17.Relations with other known use cases (optional) 

9.12.2.18.Smart contracts used 

A smart contract is defined including the list of data hashes accessed by data controller and processors, and the 
encoded usage control policy specifying the privacy preferences of the data subject stating how his/her data is 
allowed to be used. 


9.12.2.19.Merit over traditional ledger 


In traditional centralized ledgers data subjects have no way of auditing and verifying (1) the set of data 
accessed by data controllers and processors and (2) how the provided data is being used. 


9.12.2.20.Use case concerns, issues, 
In public blockchains scalability is an issue considering the amount of data accessed, stored, and processed by 


many data controllers and processors. Maybe this approach is more viable for very sensitive data, for example, 
medical records. 
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9.12.3.Commercial fish stock management 
9.12.3.1.Brief description 


Effectively managing fish stocks is not only necessary for the health of our oceans but also for the economic 
stability of the estimated 650 million [1] people directly dependent on the fishing industry for their livelihoods 
and survival. 


Evidence has shown that over-fishing of certain fish stocks has led to a disruption in the marine food-chain. 
This disruption has had devastating effects on the delicate ecosystem which relies on this food-chain [2]. 
Accurately recording and tracking the amount of fish taken from the ocean by human fishing activity is 
necessary to manage global fish stocks and avoid these periodic disruptions to the marine food-chain. 


As such, this use case will propose a blockchain solution for the effective management of commercial fish 
stocks in wild fisheries. 


9.12.3.2.Detailed description 


Fishing can be divided in three principle sectors namely; commercial, traditional and recreational. This use 
case will focus on the management of commercial fish stocks in wild fisheries. Aquaculture will not be 
considered in this use case. 


As outlined in section 1.1, overfishing of one species in the marine food-chain, can have devastating 
consequences for other species that are reliant on said food-chain. This disruption can cause an entire marine 
ecosystem to collapse and decimate overall fish stocks. 


Blockchain technology can be used to provide an effective and efficient solution to manage commercial fish 
stocks. This solution would see all fish harvested from commercial fisheries, recorded and tracked on a 
blockchain as they moved through the different phases of the fish stock supply chain. 

Such a solution can be divided into two high-level operational modules, namely; 


1) Asset Creation 


The creation of a digital asset on a blockchain which represents a real-world object (i.e. asset 
digitization). 


2) Asset Tracking 


The tracking of said digital asset on a blockchain through various phases of the fish stock supply 
chain (as outlined in section 1.5). 


The benefits of using blockchain technology to manage commercial fish stocks would increase efficiency and 
adherence to existing regulatory compliance within this industry. By using blockchain technology an accurate 
dataset of fish stocks landed by the commercial fishing fleet would also be created. Transparency within the 
fish stock supply chain would also be increased for all actors within this use case. 


9.12.3.3.Scope and objectives 

The scope of this use case is to provide a potential use case for blockchain technology in the fishing industry. 
This use case will act as an initial example of how the chosen industry could benefit from blockchain and/or 
distributed ledger technologies. 

9.12.3.4.Additional information 


Practical implementations of this use case may involve integrating with numerous off-chain services and/or 
technologies. 


For example this use case may deploy the use of IoT (internet-of-things) devices to aid in data capture at 
various stages of operation. These devices may not act as full nodes within the prosed blockchain architecture. 
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9.12.3.5.Context/Setting 

This is a brief description of the context/setting/industry surrounding the use case. 
Use case vertical application field/domain: e.g. financial services, manufacturing... 
Use case vertical subdomains: e.g. cryptocurrency, mutual funds... 

Use case horizontal activity: e.g. asset management, notarization... 


The context for this use case relates to managing commercial fish stocks harvested from wild fisheries and 
those who operate within this subset of the wider fishing industry. 


Actors within this use case include; fishers, wholesalers, fish-mongers and consumers. It is noted that this list 
of relevant actors is a simplification of actors within the real-world commercial fish stock supply chain. 


9.12.3.6.Actors 


Actors 


Actor Description Additional Information/ Identity 
technology types(Natural 
persons/Legal 
entities/Things/ 

Process) 


Actor name Actor type 


Actor who harvests Fishers who take fish Person 
fish from the ocean. from commercial fish 
stocks in wild fisheries. 


Fishers Participant 


Actor who buys Person 
fish from fishers in 

a wholesale 

capacity and 

distributes them to 

fish small scale 

fisher suppliers or 

fish mongers. 


Wholesalers Participant 


Fish- 
mongers 


Consumers 
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Participant 


Participant 


A small scale fish 
supplier. 


End consumer of 
fish or fish 
products. 


Person 





9.12.3.7.Interaction between Actors and User Requirements 
9.12.3.8.Use case diagrams / tables 

9.12.3.9.Data Flow Diagram of Use Case 
9.12.3.10.Pre-conditions or requirements or assumptions 
9.12.3.11.Post-conditions 

9.12.3.12. Technical architecture of the use case (optional) 


9.12.3.13.General implementation considerations: conformity aspects and critical requirements 
(optional) 


Considerations on authentication, asset management, identity management, traceability management, 
contract and business process automation 


9.12.3.14.Security and privacy 

9.12.3.14.1.Fishing grounds 

Due to the protective nature of fishers in relation to fishing ground location, precise coordinates of where fish 
stocks were found could be considered as a commercial trade secret. As such the public, transparent and open 
nature of data stored on a public-blockchain might not be acceptable to fishers operating within commercial 


fishing industry. 


To alleviate this potential issue a solution should be built into the system which would obscure precise GPS 
coordinates of said fishing grounds. Said solutions could include the follow; 


* Encrypting GPS coordinates with the public-keys of actors deemed to be non-competitive to fishers. 
(e.g. regulatory bodies) 


e Fuzzy matching of GPS coordinates as opposed to precise locations of fishing grounds. 


* [Implement a zero -knowledge-proof(s) which would guarantee that fish stock was taken from a 
geographical valid location, without the need to divulge a precise GPS location. 


9.12.3.14.2.IoT devices 

As mentioned in section 1.4, this use case may and very likely will deploy the use of IoT devices to aid in data 
capture. As these devices may not be full nodes within the blockchain solution, extra attention should be paid 
to ensure these devices are temper-proof and that data produced by these devices is accurate and valid. 
9.12.3.15.Legal considerations (optional) 

Legal Contracts, Legal Regulations, and Constraints 


9.12.3.16.Referenced standards and/or standardization committees in relation to this use case (optional) 


xxvi. The State of World Fisheries and Aquaculture, Food & Agriculture Organization of the United Nations, 
2014, ISSN 1020-5489. 


xxvii.Managing Fish stocks; accessed 30/01/2018 11:43 GMT  https://thefishsite.com/articles/managing-fish- 
stocks 





xxviii.European Maritime and Fisheries Fund (EMFF); accessed 30/01/2018 12:04 GMT https:// 
ec.europa.eu/fisheries/cfp/emff en 
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9.12.3.17.Relations with other known use cases (optional) 
9.12.3.18.Smart contracts used (optional) 


The successful rollout of any new technology can be a troublesome endeavour, with technology in the 
regulatory space further compounding this difficulty. 


To facilitate a seamless adoption of the proposed blockchain solution a phased rollout of this solution would 
be suggested. During the initial phase of said rollout an incentive could be offered to those in the fishing 
industry to award early adopters. For example this incentive scheme could tie in with existing schemes such as 
the European Maritime and Fisheries Fund (EMFF) [3]. 


Such an incentive scheme could be administered and automatically managed through the use of autonomous 
agents or smart contracts. 


9.12.3.19.Merit over traditional ledger 
9.12.3.20.Use case concerns, issues 


As with any tightly regulated industry there is always a concern that a non-regulated or “black market” 
industry should emerge, comprising of detractors who choose to operate outside of the regulated space. 


Therefore sufficient policing and penalties for those who fail to comply with regulatory requirements should 


be put in place. As this use case covers commercial fishing, such a penalty should focus on economic viability, 
ultimately making operation outside the regulated market place economically unviable for detractors. 


9.12.4.Sharing economy 
9.12.4.1.Brief description 


A sharing economy is a P2P platform between providers and customers. Blockchain and DLT can be used to 
operate a sharing economy platform without a centralized platform. 


9.12.4.2.Detailed description 


Sharing economy is a form of economic activity where platforms enable providers and customers to exchange, 
often underutilized, goods and services using information technology to entry. 


It is 
a) often peer-to-peer; 
b) fora fee or for free; 
c) often sequential use; and 
d) mutually beneficial. 


Blockchain and DLT can deal with the important elements of a sharing economy such as contracts between 
Provider and Customer, reputation, identity, payment, history and so on without a centralized platform. 


9.12.4.3.Scope and objectives 


9.12.4.4.Blockchain and DLT based sharing economy platform is for resolving some ploblems of 
current sharing economy platform. 
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9.12.4.5.Additional information 
9.12.4.6.Context/Setting 


9.12.4.7.This use case is common sharing econmy platform. This is not single category of sharing 
economy service such as ride sharing and space sharing. This cover all categoly of sharing 
economy service on single system. 


9.12.4.8.In this use case, there are not centralized platformer of sharing economy. This platform works 
with Blockchain and DLT based trustless system. 


9.12.4.9.Actors 


This is a list of actors in the use case. 


Actorname Actor type Actor Description Additional Information I d en t i t y 
technology types(Natural 
persons/Legal 
entities/Things/ 
Process) 


Provider Individual or entity Individual or entity that Person or legal entity 
that provides assets provides assets or 
or services to services to customers who 
customers want access to those 
assets or services, using a 
sharing economy 
platform. 


Customer Person or Person or organization Person or legal entity 
organization that that uses a sharing 
uses a sharing economy provider's 
economy provider's assets or services. 
assets or services. 


Platform Platform facilitate Information technology Process 
between Provider mechanisms that facilitate 
and Customer the ability for transactions 
to take place between 
those who have assets and 
services and those who 
want to use assets and 
services. 





9.12.4.10.Interaction between Actors and User Requirements 


All providers' and customers' identities must be verified by some accrediteds or authorized organizations. 
Abusive participants can be removed by specifying the identity. 


9.12.4.11.Use case diagrams / tables 


See Data Flow Diagram of Use Case. 
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9.12.4.12.Data Flow Diagram of Use Case 


Provider Platform Customer 


Register assets 


Register information of 

assets, price, requirement 

to use and detailed Find asset and check 
reputation and request to 
use. 


Publish the request from 


Customer. 
Check reputation of 


Customer and permit to 
use their assets. 


Conclude smart contract 


Fee from Customer is 
locked by smart contract 
(escrow function) 


Use the shared asset. 


Fee is moved from 
Customer to Provider by 
smart contract. 


Submit review Submit review 


Record review and 
reputation from Provider 
and Customer. 





9.12.4.13.Pre-conditions or requirements or assumptions 


Provider and Customer trust the Platform. If Platform is centralized and it performs abusive behaviour, 
Provider and Consumer may not notice. 


9.12.4.14.Post-conditions 


All records in Blockchain or DLT are immutable. By valifying the record, anyone can detect abuse. So, 
Provider, Customer, Platform is unable to perform abusive behaviors. 


Even if there is no centeralized administrator, this sharing economy platform can keep safe. 


9.12.4.15. Technical architecture of the use case (optional) 


9.12.4.16.General implementation considerations: conformity aspects and critical requirements 
(optional) 


All Providers and all Customers must be identified. This is strong way to remove abusive behavior. 
All reputations and reviews must be available to all users to view. This is base of trust. 


The Platform must not write identity data to the Blockchain and DLT. 
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9.12.4.17.Security and privacy 


The Platform must not write identity data to Blockchain and DLT. Identity data must be written to a deletable 
data store. 


9.12.4.18.Legal considerations (optional) 


Applicable laws are different depending on shared assets and region. The provider, customer and platform 
must comply with the law. 


9.12.4.19.Referenced standards and/or standardization committees in relation to this use case (optional) 
IWA27:2017 Guiding principles and framework for the sharing economy 
9.12.4.20.Relations with other known use cases (optional) 
9.12.4.21.Smart contracts used (optional) 
Smart contracts are used: 
e to identify Providers and Customers; 
* for payment and escrow with contract; 
*  torecord the reputation and reviews of participants; 
*  toexecute the Decentralized Autonomous Organization. 
9.12.4.22.Merit over traditional ledger 


The centralize service platformer will be removed. Fees to use the service can be reduced. Finally, sharing 
economy will be a decentralized autonomous organization (DAO). 


9.12.4.23.Use case concerns, issues 


10. Use cases findings 

10.1.Potential common requirements 

10.1.1.Common requirements across domains and application types 
10.1.1.1.Identity 


Identity is a basic foundation upon which blockchain and digital ledger technology is built upon. The ability to 
identify something or someone is fundamental to the ability to keep track of or record the value of something. 
Depending on the different applications of blockchain and DLT, there are different requirements for identity. 
Some identity requirements include the identity of assets, entities, people, things, devices, and processes. 
Identities for different objects and entities will have different properties, such as the type of object or entity 
and relevant details that uniquely identify them. Methods to securely and digitally identify an entity or thing 
will increase the ease of use and interoperability of different blockchains and DLTs. 


10.1.1.2.Security 


Transparency allows blockchain and DLT transactions to be auditable so it's vitally important that information 
written to the blockchain is secure and tamper proof to ensure that transactions can be trusted. Sensitive and 
confidential information written into the blockchain may need to be encrypted. Solutions to manage the 
cryptographic keys are necessary to ensure security. 
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10.1.1.3.Privacy 


Due to the transparency of blockchain and DLT transactions, the need for information privacy is increasing. 
Participants may not want all details of their transactions to be known or the information may be confidential 
in nature. In addition, since transactions are auditable by third parties, all transactions past, present, and future 
can possibly be tracked, mined, and analysed. By analysing the transactions of a participant, other possibly 
private information can be inferred, such as transaction partners, history, patterns and even geo-location 
history. 


Privacy solutions need to be developed that protects the privacy of participants and maintains a balance with 
transparency and auditability. Solutions could include obscuring, encrypting, or anonymizing personal and 
sensitive information or methods to setup policies to grant and revoke data access permissions. 
10.1.1.4.Compliance to data protection and storage regulation 

Depending on the jurisdiction where the blockchain and DLT applications are used, various types of data 


stored in the blockchain will need to comply with local regulation regarding the collection, protection, usage, 
and storage of specific types of data. 


10.1.2.Common requirements specific to domains 

10.1.2.1.Finance 

The financial industry places importance on the timeliness of financial transactions. Since settlement times 
can affect the value of transactions or the time to perform transactions, very short or real-time transaction 


settlement times on the blockchain are important for many financial applications. 


Certain financial applications of blockchain and DLT such as cryptocurrency need to be legal or at very least, 
not illegal in the jurisdiction where they're used. 


10.1.2.2.Healthcare 


Blockchain applications that store healthcare data will need to comply with local laws and regulations 
regarding the collection and storage of healthcare data. The regulations will differ depending on jurisdiction. 


Healthcare data can be complex and can be prone to errors. Processes or methods must be in place to correct 
errors in the data. 
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10.1.2.3.Real estate 

10.1.2.4.Energy 

10.1.2.5.Identity management 

10.1.2.6.IoT 

10.1.3.Common requirements specific to application types 
10.1.3.1.Asset management 

10.1.3.2.Notarization of transactions proof and timestamping 
10.1.3.3.Storage of digital proof and tracking 


10.1.3.4.Smart contract activity 
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Use cases repository 


Many use cases were proposed in the group but is not written in detail yet. 


All proposed use cases are listed on the use case repository as below. 


Use Use Case Name Use Case Description Proposed | Status 
by 


Managing lifetime A healthcare use case that proposes the use of T o n y|Inwork 
healthcare data blockchain technology and/or distributed ledger | Winters 
technologies to manage the lifetime healthcare 


data record for an individual. 


Smart inheritance This use case describes a public service B e n o î t| In work 
proceeding implementing statutory and wilful inheritance on | Abeloos 


blockchain, using smart contracts. 


Use of the Use of the blockchain as a ledger to register Michelle | Proposed 
Blockchain for securities Abraham 
securities 


Energy distribution | A solar energy production and distribution Ioannis|In work 
with the use of smart | architecture using smart contracts, to support Kounelis 
contracts automatic energy exchanges and auctions. 


Smart contracts for | Smart contracts can be used to track data Benoit|Inwork 
data accountability | provenance and encode usage control policies Abeloos 

and provenance regulating the access and usage (e.g., 

tracking redistribution) of subject's data by controller and 


processors 


Title registry system | Blockchain real estate pilot programs being Manohar] In work 
using blockchain developed for land ownership administration Velpuri 
land ledger 


Managing residents | Managing civil Identity proof and trusted list of |S o p hi e| Proposed 
identity and refugee in europeen countries Coutor 
licensing refugee ID 
votation/ voting Secure and up dated account of vote . S o phi e | Proposed 
systems Coutor 
Borders countries Secure trusted maping, managed by UNO S o p hi e| Proposed 
maping Coutor 

Proposed 


Smart securing of public service implementing diplomas in a Sophie 
diplomas (or secure and trusted way (or intellectual property | Coutor 
intellectual using smart contracts) 


property...) 
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Self Sovereign 
Identity 


Credential 
Revocation 


Reconciliation case 
based on DLT 


Land Development 
pipeline 


Supplier bank 
guarantees 


Energy certificates 
of origin 


Energy trading 
settlement 


Self Sovereign Identity on the web rather than 
identifiers being controlled by another entity. 
Users register an anonymous identifier that they 
can solely prove ownership of. This not only 
gives them single sign-on capabilities to 
participating websites but digital credentials of 
any kind, like a drivers, can be issued to the 
identifier that only they control. 


A teacher certification is issued to a particular 
person by an an educational institution. Teachers 
are required to fulfill periodic testing 
requirements to maintain their teacher 
certification. If these requirements are not met 
the educational institution can write the 
revocation of the teacher’s certification to a 
revocation ledger(a.k.a bockchain). When 
teacher certifications are inspected the 
revocation ledger is queried to verify that the 
teacher certification is up to date. 


Sharing Economy is multiside platform between 
sharer and sharee. Blockchain can deal with the 
imporant element of sharing economy such as 
contract, reputation, identity, payment,hitsory 
and so on without centralized platformer. 


The platform is a pioneering blockchain 
application for a “distributed business scenario”, 
where a high level of interbank operational 
efficiency, process automation and system 
reliability are required to ensure cost efficiency 
and business continuity. 


Blockchain, or a similar capability, is potentially 
well suited to documenting and distributing 
property development information, and 
providing an authoritative source of information 
for the broad range of participants. 


Redfined previously highly manual process, by 
developing a system where bank gauarentees 
become digital contracts represented by a 
Blockchain record and equally accessible by all 
counterparties 


A certficiates of origin system for generators and 
buyers of renewable energy that enable CO 
issuance, tracking & retirement through smart 
contracts on a distributed ledger 


Secure, real-time blockchain-based digital 
platform to manage physical energy transactions 
from trade entry to final settlement 


T a k e o| Proposed 
Nishikata 
T a k e o| Proposed 
Nishikata 


E 


i 


w e n|Proposed 
n 


O w e In work 
Williams 
O w e n|Proposed 
Williams 
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Gas & power trading | Peer to peer trading in the wholesale energy O w e n| Proposed 
market (i.e. gas & power) through a blockchain | Williams 
enabled platform 
Component Smart contract based system developed to enable |O w e n| Proposed 
aftermarket shorter spare part lead time, lower inventory and | Williams 
improved customer centricity in the component 
aftermarket 


New Motor Vehicle | Whether a car is manufactured or imported there |G a r y | Proposed 
Sale Cycle are a range of different organisation involved in | Folland 

enabling the final sale of that vehicle to a 

consumer. There are vehicle compliance plates, 

registration and taxes and fees. If the vehicle is a 

luxury vehicle there are some benefits in 

tracking providence for resale. DLT could allow 

for the incremental building of all of this 

information from various sources to speed the 

time taken to deliver the vehicle to the customer 

and improve process integrity. If the vehicle is 

imported it could also cover the supply chain 

logistics 


Cryptocurrency for | Use cryptocurrency for machine to machine T a k e o| Inwork 
M2M payments payment Nishikata 

Identity management | Blockchain is providing a secure technology asset and | Paul Ferris | In work 
with the use of trust framework to the process of Border control 

blockchain for border 

control 


Supply chain Blockchain is providing a new way to record Caroline | In work 
management and the Provenance across supply chains, enabling more Thomas 
use of blockchain efficient trade and access to trade finance 


Payments and Blockchain is providng a platform for encrypted Paul Ferris | Proposed 
cryptocurrency digital currencies that can be used to make payments 

for goods and services for government and other 

services 
Commercial fish A blockchain solution for the effective T o n y|Inwork 
stock management | management of commercial fish stocks in wild Winters 

fisheries. 


VAT Coin Transactions containing GST or VAT are written |G a r y | Proposed 
to a blockchain and a tax credit token is Folland 
generated. This token is fixed in value to a FIAT 
currency. Balancing off occurs daily and only 
legitimate supply chain credits that have been 
verified are available to withdraw from the 
system addressing carousel fraud and immidiecy 
of credit and debit tax payments or entitlements. 


Triple-entry Using blockchain, smart contracts and API's to G a r y| Proposed 
bookkeeping automate recording and collation of accounting | Folland 


records 





© ISO 2017 — All rights reserved 
79 


Blockchain Grants 
awarding 


Welfare payments 
on blockchain 


Supply chain 


License agreement 


Machine-machine- 
interaction 


Machine-machine- 
interaction 


Monthly payment 


80 


Using blockchain to add transperancy to the 
issue and usage of Government grants. Similar in 
practice to the use case around charities 
donations but involves wider variety of 
recipients in the network. Recipoients of grants 
will receive there funding via blockchain credits 
and grant recipients will need to use suppliers, 
services and products that are part of the 
network. 


Using blockchain to ensure that welfare 
payments are used on essential expenditures for 
those in vulnerable communities. Paying a 
component of the welfare payment to a 
blockchain where the tokens are only redeemable 
(with limits able to be managed with smart 
contracts) so that welfare payments for food, 
care of children, healthcaare, public transport etc 
are able to be protected. 


A good is transported from a to b. Sales contract 
is individually agreed. A smart contract shall 
monitor the conditions of good. After arrival in 
time and with well treatment, payment will 
automatically initiated. 


Music is bought (?) via internet - (Spotify). The 
association of owners, licenses, E is managed on 
the blockchain. 


What was really bought? Music, the license to 
play, rented? 


An empty fridge orders new food online. 


Who really buys? The fridge or the owner? 


There is only 1 license for a roboter to produce 
goods. But there is an additional spare roboter 
for replacement. The first roboter "simulates" a 
defect and the license for production is 
automatically transferred via the chain to the 2nd 
roboter. Now the Ist roboter was quickly 
disconnected from the network - and it is not 
really defect. Therefore the transferred license 
we deactivated for the 1st roboter on the chain, 
but never physically deactivated. Now 2 roboters 
are producing with 1 license. 


Somebody has agreed on monthly payments to 
his children for financing their studies. It is 
transferred on ethereum by a smart contract. 
Now this person dies and his login data are lost. 


How can the payment be stopped? 


G a 
Folland 


r y|Proposed 


G a 
Folland 


r y|Proposed 


Skwarek/ | Proposed 
DE 


Skwarek/ | Proposed 
DE 


Skwarek/ | Proposed 
DE 


Skwarek/ | Proposed 
DE 


Skwarek/ | Proposed 
DE 
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Energy Trade 


Grid stability 


Authorization to 
release goods 


The grid-energy balance could be automatically 
regulated by smart contracts by buying missing 
energy automatically from power plants, or a 
surplus can be stored. This can directly be 
combined with trading and bidding for getting 
most energy for the lowest price. 


Legal? Overregulated system! 


Energy can automatically be routed via the 
optimal way through the grid for the most 
efficiency grid use and least energy loss. This 
data should be public as every grid node could 
have an own (financial) interest in getting most 
of the energy through its own part of the grid. 


A smart contract coordinates and records some 
debt ("A" lends money to "B", including amount, 
interest rate, repayment terms, etc). The debt 
may be represented and traded as a token. As 
repayments are made, the smart contract 
distributes them to token owners. 


If B does not repay, what mechanisms can be put 
in place to recover the funds? 


Tokens, representing rights to goods, keys to 
locations/lockers, or 3rd party digital assets, are 
transferred between parties. For example, an 
organization that outsources its warehousing can 
transfer a token for possession of goods from the 
warehouse to the buyer, thus providing clearance 
to the third party warehouse to release the goods 
to the buyer. 


What recourse will the buyer have if the third 
party only partially fulfils the transfer of goods? 


Smart contracts need to be written to allow 
changes to quantities and timings. For example, 
perhaps 100 items are sent by A to a warehouse 
under a contract with B. Then B discovers it only 
needs 50 and A discovers a buyer C who will pay 
more than B — so both parties want to change the 
quantities and instead of one token for 100 items, 
2 tokens for 50 items each are needed. In another 
scenario, perhaps 20 items are damaged in 
shipment and A and B agree that only 80 will be 
delivered, requiring, again, a change. These 
types of scenarios are not unusual in the “real” 
world. 
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Tracking exchanges | Tokens as proxies for physical assets (e.g., Eric Cohen/ | Proposed 

under warranty serialized computer equipment) are tracked to 
ensure that items are properly exchanged in a 
warranty situation. For example, buyer ships a 
physical computer needing repair/exchange; 
seller ships a physical computer (new/repaired) 
back; smart contracts not only exchange asset 
tokens but can exchange cryptocurrency between 
parties as needed for mailing costs or other 
charges.IoT can be used for tracking the location 
of the tokenized item, thus determining who has 
the token. Without IoT, other methods of 
verification are needed (for example the seller 
could verify receipt of the computer to be 
repaired and then the buyer of the repair could 
verify that the returned computer is the one that 
was sent and is, indeed, repaired). Even with IoT 
some external verification (for example that the 
computer is repaired and working) will be 
required. 


Escrow/earnest Smart contract ensures that amounts placed in Eric Cohen/ | Proposed 
money, deposits escrow (potential home sale) or deposit (rental 
(e.g., security agreement) are either transferred to the selling/ 
deposit, Kickstarter) | landlord party or are returned to the buying/ 
tenant party in whole or in part as agreed in 
advance based on conditions that could range 
from a simple date to a good inspection report to 
the finalization of a home purchase. 


This would provide home purchasers and renters 
guarantees that their escrow money and rental 
deposits will be refunded in a timely manner 
after conditions are met and will not be retained 
for long periods or “stolen”. 
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Rebates 


Microloans 


When goods are purchased with rebates, Eric Cohen/ | Proposed 
purchasers could be automatically credited the 
amount of the rebate on the blockchain. This 
payment would be automatically triggered via a 
OmessageO from the retailer to a smart contract 
on the blockchain with the amount purchased 
and the location of the purchaser's blockchain 
wallet. This would avoid the purchaser having to 
send proofs-of-purchase to the manufacturer and 
save the manufacturer having to verify and 
process the proofs of purchase and resulting 
payments. The scourge of office supply buyers, 
goods are sold with rebates to make them 
affordable, but the effort of providing proof of 
purchase and mailing paperwork, as well as the 
loss of paperwork that might be needed at a later 
time calls out for an electronic solution where 
the process and payment from beginning to end 
can be properly tracked. 


Tracking and releasing microloans based on Eric Cohen/ | Proposed 
conformance with certain requirements 
registered on the Blockchain. 


What is the recourse of the borrower if they 
believe they have met the requirements but the 
OoracleO submitting this information to the 
blockchain does not agree or fails to 
communicate this information? 


The security “weak point” in blockchain 
applications is very seldom the blockchain itself, 
rather it is the systems that provide information 
to the blockchain (and sometimes poorly 
designed smart contracts). Therefore, especially 
in financial applications such as this, security 
standards for the “oracles” providing information 
to the blockchain could provide important 
implementation support. 
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45 Buying groups Discounts are offered to groups who agree to Eric Cohen/ | Proposed 
aggregate their purchases with the price either 
varying depending upon the quantity ordered or 
the sale being executed at one agreed price, but 
only once a minimum order quantity is reached. 
This is often done using intermediaries who 
consolidate the purchase requests. A smart 
contract could keep track of the quantity ordered 
(and who placed the orders) and automatically 
charge the purchasers and request shipment of 
the goods once the minimum quantity is met 
(and/or determine the price when this is variable 
in function of the quantity). This could reduce 
costs for all purchasers and vendors, and perhaps 
eliminate the need for intermediaries. In Europe 
and North America group buying is done almost 
exclusively through online intermediaries (in 
Asia it is often self-organized by the purchasers). 
Interested buyers are, most often, asked for 
credit card details, which will be charged only 
when a required number of buyers register. 
Intermediaries charge vendors a large percentage 
fee (up to 50% of the total value of the whole 
deal). Blockchain could eliminate these 
intermediaries allowing vendors to provide even 
larger discounts to group buyers. 


Zipcar/Bike rental/ | Physical items as well as services can be used, Eric Cohen/ | Proposed 
boat rental/WIFI/ tracked and billed by smart contacts based on 
phone transactions and IoT information entered into the 

Blockchain. 
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Natural capital/ Transactions entered into Blockchain trigger Eric Cohen/ | Proposed 

carbon credits evaluation of their environmental impact and 
allocate awards/penalties or simply provide 
information about total environmental impact for 
use by consumers and/or companies and/or 
governments. There are increasing demands for 
calculating the carbon emissions and/or overall 
environmental impact of products. This is 
currently extremely difficult to do because of the 
large number of parties in typical supply chains 
and the fact that not all parties (for example sub- 
contractors or transporters) are known to the 
buyer and/or the seller in advance. With 
blockchain, some of this information (such as 
distance travelled) can be collected via IoT 
devices. Other information, however, still has to 
be entered by parties along the supply chain. 
This is simplified because the supplier of 
information does not have to know to whom the 
data is sent, they can just send it to a blockchain 
address that is barcoded or RFIDed onto a 
product BUT they still have to: know that they 
have to send information; know which 
information to send; and agree to send it! 


Proof of purchase Smart contracts can provide a credential token Eric Cohen/ | Proposed 
required to make an | that authorizes a buyer, whose purchase is 
entry (review / entered into a Blockchain, to enter a review/ 
reputation service) critique of the product they purchased. This 
ensures that only actual purchasers are able to 
provide reviews. 


There are many electronic commerce platforms 
for goods and services that depend upon 
customer reviews to sell products and as a 
service to purchasers. Today, these are gradually 
losing credibility as some sellers “cheat the 
system" by entering false reviews or even use 
bots and texts generated by artificial intelligence 
to do this on a large scale. 


Release of A smart contract could track debt payments Eric Cohen/ | Proposed 
mortgage/lien where there is a mortgage or lien and UNECE 

automatically end/release the mortgage or lien 

when the debt has been paid off in its entirety. 





© ISO 2017 — All rights reserved 
85 


Licensure, A combination of exam results, experience, Eric Cohen/ | Proposed 

accreditation token | payments, and other requirements (such as 

AND Update date residency in a specific geographic zone) result in 

on license/permit/ individuals having valid licenses or 

certification accreditations and some of these must be 
repeated at specified intervals in time. The 
blockchain could track the licensed status of 
professionals and grant them the right to provide 
information to the blockchain accordingly — and/ 
or provide employers and professionals with a 
source of “proof” of qualifications. For 
example, a Certified Public Accountant (CPA) 
could only sign a Blockchain stored financial 
report if they had the appropriate tokens showing 
them to be both a licensed CPA and the the 
auditor of record for the organization. 


Access to rentals Using smart contracts and IoT, locks could be Eric Cohen/ | Proposed 

including hotel/ installed that only allow access to rented 

home entry facilities, vehicles or equipment to those who 

(AirBnB) have the correct numeric keys (distributed by the 
blockchain) or whose identity matches that 
registered on the blockchain. These could be 
subject to both payments and other conditions 
and time-limited. The smart contract could even 
require users to match registered biometric data 
(eye scans, fingerprints, etc) before issuing the 
instruction for an IoT device to open a lock. 


For example, such blockchain-based systems 
could simplify hotel room and AirBnB rentals, 
eliminating the need for checkin and the 
collection of keys for facilities. It could also 
allow car and truck rentals to be automated and 
increase security (for example for the rental of 
trucks that could be used for terrorist attacks) by 
requiring biometric validation of the renter’s 
identity. 
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intervention. 


Increased security in | Smart contracts could check those wishing to Proposed 
the sale or trade of | purchase or sell controlled substances and only 
controlled allow completion of the transaction when 
substances requirements are met (such as having an export 
or import license for environmentally dangerous 


Building and Using smart contracts and IoT, locks could be Eric Cohen/ | Proposed 
facilities access/ installed on buildings or facilities that smart UNECE 
security contracts will only open subject to conditions 

that could include: an employment contract, a 

technical certificate, a work assignment, security 

clearance, matching registered biometric data 

(i.e. eye scans, fingerprints), etc.For example, 

such blockchain-access systems could allow 

repair or cleaning people to enter facilities, 

workers to enter high-security buildings or 

restricted areas, etc. — all without human 


products or having a prescription from a licensed 
medical professional for drugs) 


Reputation tokens Common, smart contract driven system to award | Eric Cohen/ | Proposed 
and remove reputation token (a la eBay) based UNECE 


on activities entered as transactions. 


Unlocking Smart contracts could control access to Eric Cohen/ | Proposed 
knowledge/resources | information such as health records, educational | UNECE 

with token — materials, or other content by only allowing 

attributes about them to be “unlocked” by those with the 

identity appropriate token attributes, i.e. (this person is a 


NY Certified Public Accountant, this person is a 
registered nurse at hospital X, etc). 


Auto-destruct code | Destruct sequent 1, code 1-1 A Eric Cohen/ | Proposed 
(star trek) UNECE 


Enforcement token | Is that person really from the FBI? Is that Eric Cohen/ | Proposed 
(for on- Blockchain | warrant real, or counterfeit? Publicly checkable | UNECE 
or off- Blockchain Blockchains driven by smart contracts can assess 


actions) tules and timing to provide proof of the validity 
of enforcement actions. 
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Track bartering Bartering groups can track contributions to and | Eric Cohen/ | Proposed 

groups, membership | usage of credits in a bartering environment. 

programs for shared | Smart contracts would decide how much a 

resources particular item or service is worth in“barter 
tokens”. Smart contracts can also be used to 
decide upon access to shared facilities in a 
membership program where there are rules 
governing the sharing of common resources 
(which could range from sailing boats to 
vacation apartments to educational classes with 
limited *seats").How would disagreements about 
the value in terms of barter coins of a particular 
item or service be resolved? 


Track solar/power A smart contract can allocate power use on a Eric Cohen/ | Proposed 
contribution to a local shared energy grid according to pre- 
shared energy determined rules and track power generated, 
network power used and the cost of any power purchased 
from an external grid in order to determine 
balances and make charges or payments to 
participants as appropriate. 


Crowdsourced Is that Justin Bieber, Taylor Swift or Super Bowl | Eric Cohen/ | Proposed 
“Ticketmaster” ticket authentic, or is someone trying to cheat me | UNECE 

and selling me a fake? Smart contracts can be 

used to oversee ticket exchanges and usage by 

only transferring proven tickets between parties. 
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Use cases guidelines 


The following guidelines are adopted by TC307 SG2 for writing uses cases: 


e Take into account the current market conditions 

* Provide a framework for future technological development 

* Be comprehensible to qualified people who have not participated in their preparation 
* Use plain language 


O 


OOo00 


O 


Be clear about main message 

Keep sentences short and concise 

Use short simple words 

Use lists whenever possible 

Use active voice 

Use everyday language and avoid jargon 


* Avoid referring to trademarks or companies. Patented items can be referred to under certain 
conditions (see ISO/IEC Directives, Part 1). 

* Nolegal or contractual requirements. 

* Directive 2 


O 


O 


O 


O 


Fitness for implementation as a regional or national standard 
a Choose characteristics that are suitable for international acceptance. 
» Where necessary, options may be indicated (e.g. owing to differences in legislation, 
climate, environment, economies, social conditions, trade patterns). 
Performance principle 
a Express requirements in terms of performance rather than design or descriptive 
characteristics 
= Care shall be taken to ensure that important features are not inadvertently omitted 
from the performance requirements 
Verifiability 
» Requirements shall be objectively verifiable 
» Avoid mandatory use of services, such as testing or certification (e.g. by another 


company). 
= Write the requirements so they can be verified by anyone 
Consistency 


» Maintain consistent structure, wording, and terminology 
a Be clear and accurate 
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